Re: [Xen-devel] [Outreachy] Interested in contribution: Code Standards Checking using clang-format

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Hi Ishani,

> On 3 Apr 2017, at 13:01, Ishani <chugh.ishani@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> Thanks for the reply. I started with looking into format of Xen Hypervisor 
> files and creating a clang format file for the same. However, given the 
> present implementation of clang-format, it is not possible to incorporate 
> fine-grained custom coding format requirements. For example, although 
> clang-format provides a custom brace wrapping format specification, it is 
> still not sufficient to incorporate the do while loop exception for braces in 
> Xen Hypervisor format.

OK, this makes this project a lot harder. I don't think we are particularly 
tied to clang-format. 

> The implementations is presently on higher layers of abstraction and needs to 
> be fine grained to allow for different types of loops as well. I figured that 
> there are two ways of doing it, First , by creating a wrapper over 
> clang-format and using regexes to find appropriate partitions of code to 
> follow different format styles.
> However, this will be rather cumbersome with multiple heuristics and we will 
> lose the advantage of clang-format tool using the inbuilt parser.

Indeed.

> Second way is to extend the functionality of clang-format. I have experience 
> working with compilers. Going through the code of clang it seems possible to 
> include kw_do token for do while loop as a functionality for braces wrapping( 
> although it would require a very thorough reading through the codebase 
> first). 

One of the objectives behind using clang was that we wanted to be able to use a 
compiler front-end that has a plug-in model or a library which allows access to 
the AST. Clang-format appeared to fit the bill. 

> At present, I am working on creating a clang format file supporting subset of 
> coding formats for Xen Hypervisor.

I think that would fit with what I suggested.

> Can you provide me with some more insight into the project?

There are really two objectives:

A) A tool which can be run over submissions by new contributors. Right now, 
adherence to coding standards has to be manually checked. Having a tool which 
lists coding standard violations in a git-patch or in the files a patch touches 
would allow contributors to run the tool before submitting the code. Ideally, 
it could be run over a patch, but that may be harder than running it over the 
files the patch touches. In any case, it would improve the work-flow.

B) Be able to run the tool on the entire code base.

We also want to make this as easy to maintain in future as possible, which is 
why we originally suggested clang-format. It might in fact be easier or cleaner 
to use LibTooling rather than clang-format for this as base-line and use 
clang-format as an inspiration (looking at the source of clang-format, there 
does not seem to be that much).  Keeping as close as possibly to the 
clang-format config file. The downside is that we would have to maintain such a 
tool in the long-run (but then we would have to do the same if we used a 
stand-alone tool using script hackery). I don't think either Doug, Andy, or me 
could give you concrete advice on what the best way forward is here without 
further discussion though.

> clang-format formats the tool to specified format. However, there are many 
> standards which include a particular format for a variable name. It is not 
> feasible for a tool to automatically change the name of variable according to 
> given standards because of possible breaking build of the code.

That is not the intention: it is definitely not desirable to do that kind of 
refactoring automatically. 

> As a part of the project, are we required to create an auto-formatter or 
> something like pylint which suggests the necessary changes and gives an 
> overall score, or a combination of both?

We don't need an auto-formatter. Just a tool - such a pylint - which runs on 
our codebase and makes suggestions on how the code should look like. This 
should make things easier. 

> I wish to apply to GSOC as well for the same project. However, since the 
> deadline is today, I will be grateful if you could provide some suggestions 
> for the project.

I see you submitted already

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel