Enum formatting changes - polly automatic formatting verifier

[Alp Toker]

On 06/01/2014 04:05, Daniel Jasper wrote:
> However, even based on your numbers, it is an even split. You find 259 
> cases in favor of single line formatting and 272 cases in favor of one 
> enumerator per line. That is as close to a break-even as it gets. 

Without weighing in on any other part of the discussion, I wonder if 
its' the _context_ of these uses that determines what style developers 
are using. If so (and you'd need to confirm this by sampling where the 
259 / 272 cases appear) then we have a very good rule of thumb to 
classify and get it right every time.

What I have seen is that one line enums, and equally one line function 
definitions, are the prevalent convention at class scope and local scope 
lexical contexts, whereas they are very rare at TU / namespace context 
(modulo automated clang-formatted code that has been committed in the 
last few months -- you should really sample the codebase from a revision 
around a year ago to avoid sampling bias).

If it holds true, I think there's a semantic value to that as well -- 
enums with global scope and visibility often correspond to other lists 
such as the LLVM dyn_cast type system, so a strict 
one-line-per-enumerator convention makes code review easier, and reduces 
churn when a new enumerator is added or removed, flipping from one-line 
to multi-line style.

Local enums are usually just a shorthand to avoid hard-coding constants 
in the function body and it makes sense to have them on one line.

Does clang-format have the smarts to identify the scope context in which 
the enums and function definitions appear?

This is something I'd really like and I think would comprehensively 
match the prevalent coding style in LLVM today, as well as WebKit and 
presumably other projects too.

Alp.


-- 
http://www.nuanti.com
the browser experts