<div dir="ltr">I have run a few numbers correcting my regular expressions based on Tobias's feedback (allowing 100 characters for enumerators to account for the whitespace etc.). I used the initial indentation in order to classify the context (assuming inside classes and functions enums would be indented). The numbers I get are:<div>
<br></div><div>No indentation, all on one line: 208.</div><div>No indentation, one per line (might fit one line): 180</div><div>Indentation, all on one line: 260</div><div>Indentation, one per line (might fit one line): 258</div>
<div><br></div><div>So, still a pretty even split and I don't see any correlation with the context.</div><div><br></div><div>I can see the argument about comments, but</div><div>a) I don't think they constitute a strong reason. Especially with the availability of automated formatting, you need only 1 or 2 additional key-strokes to add comments to a single-line enum.</div>
<div>b) You might actually make the argument the other way: If comment-less enums are put on a single line, you as an interface designer might be encouraged to write comments in order to point out the individual enumerators. :-)</div>
<div><br></div><div>All in all, my opinion is that it doesn't matter enough to validate a separate style flag or a more extensive discussion. I am happy to revisit if we get more data on this being a problem.</div><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 6, 2014 at 7:35 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 06/01/2014 06:09, Alp Toker wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 06/01/2014 04:05, Daniel Jasper wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br>
</blockquote>
<br>
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.<br>

<br>
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).<br>

<br>
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.<br>

<br>
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.<br>
</blockquote>
<br></div>
Another "semantic" explanation for how this convention appeared in LLVM, and why it makes sense to support it in formatting tools: Enumerators at TU / namespace scope are far more likely (i.e. almost always) to have visibility and be part of the API.<br>

<br>
There's an expectation that core "top-level" enums should have individual doc comments, even if there are only two or three enumerators. Bunching them into one line sends the wrong message and on a practical level makes it harder to add documentation post-review just before committing.<br>

<br>
Ditto adding drive-by docs to existing code -- if you have to split up the enum by hand the to document one entry, the effort barrier is raised higher than just writing "///< Indicates such and such", svn ci.<br>

<br>
On the other hand nobody wants or expects docs for an enum { ON, OFF } in a function local scope and those reall benefit from being on one line every time.<br>
<br>
Daniel, is this making sense from your POV?<span class="HOEnZb"><font color="#888888"><br>
<br>
Alp.</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Does clang-format have the smarts to identify the scope context in which the enums and function definitions appear?<br>
<br>
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.<br>
<br>
Alp.<br>
<br>
<br>
</blockquote>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div>