Enum formatting changes - polly automatic formatting verifier

[Daniel Jasper]

On Sun, Jan 5, 2014 at 3:58 PM, Tobias Grosser <tobias at grosser.es> wrote:

> On 01/05/2014 02:13 PM, Daniel Jasper wrote:
>
>> Tobias, could you submit the two small formatting changes that are
>> required? I am not entirely certain whether it would be ok for me to just
>> submit patches to polly. Also I don't think it would be a good idea for
>> clang-format developers to be required to ensure other projects' adherence
>> to what clang-format deems to be correct style.
>>
>
> Hi Daniel,
>
> thanks for letting me know. You are not required to fix Polly, but if
> there is an obvious and easy fix, I would be more than happy if you do so
> (it also keeps the buildbot noise down). For non-obvious changes I would
> prefer a short pre-commit mail (or just an headsup as today). However, if
> the style change is non-obvious it would be great if you could make it off
> by default for LLVM and give a short headsup on the mailing list such that
> I can prepare a patch for Polly.
>
> Regarding the change today, I wonder how you figured out that the new
> formatting is 'the predominant choice' in LLVM/clang? I just checked what
> formatting is more common in LLVM/clang by counting the one line enums in
> the current LLVM and clang code and after running the latest clang-format
> over all .cpp and .h files.
>
> I use the following grep call to count:
>
> grep -R 'enum.*{.*}.*;' tools/clang/lib/ lib/ include/ \
>                         tools/clang/include | wc
>
> I get 259 cases for the current formatting and 531 for the reformatted
> code, which means 272 cases use currently a multi line formatting.
>

I did a slightly different analysis. I searched for "enum.*}" and there
seem to be 432 files with in LLVM/Clang containing these. This compares to
a search (with multiline regexs) for "\n\ *enum[^\}]{0,73}\n\}" of which I
find 80 files containing them. The latter should be all enums that can be
written on a single line but aren't.

Without paths containing "test" these numbers change to 219 vs. 47 files.
The 5:1 ratio seems quite consistent. The regular expressions might have
errors, I only hacked at them until I was satisfied and the individual
findings were what I was looking for.

It seems the one line formatting is actually slightly less common in the
> LLVM/clang files. I also don't believe that the new style buys us anything
> in readability.
>

It still makes sense to build clang-format close to the more frequent
style. Plus, the people I talked to before-hand (Manuel, Alex and a few
other users prefer single lines).

I would prefer clang-format to remain consistent between versions,
> as long as there is no good reason to break this consistency.


I think the above (preferences of users + more similarity with existing
code) constitutes a good reason.


> Consequently, I wonder if it would not make sense to use the old style in
> LLVM mode?
>

a) Not from the numbers I had. We can do a more thorough analysis, though.
b) If there is an even split inside LLVM (as your numbers would suggest)
then I'd prefer to have fewer options.

Btw. this is not only Google Style. GNU style has this explicitly written
down, in WebKit it seems to be common.

Cheers,
Daniel

Cheers,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140105/624b9000/attachment.html>