Enum formatting changes - polly automatic formatting verifier

[Tobias Grosser]

Hi Chandler,

thanks for your feedback. I agree we wasted too much time on this 
already. So this will be my last email. I expressed my concerns. That's 
all I wanted.

As you put a lot of effort to address my concerns, I will at least 
answer briefly.

On 01/06/2014 03:12 AM, Chandler Carruth wrote:
> Regarding the enums, I just don't care about how enums are formatted. I'm
> happy to let "fewer lines of code" (a terrible metric in some cases) decide
> because of how little I care. ;] So, I don't see any real problem with the
> current change in behavior mostly because this doesn't seem like something
> worth all of us spending a ton of time on.

I don't care about the how either.

> But I'll address the more meta issue of change in clang-format and options
> across styles:
>
> On Sun, Jan 5, 2014 at 5:31 PM, Tobias Grosser <tobias at grosser.es> wrote:
>
>> What is the problem with additional options? I did not touch them once yet.
>>
>
> It's a slippery slope problem for the maintenance of clang-format IMO. I've
> pushed hard for clang-format to avoid options unless there is a compelling
> reason (large open source projects with divergent conventions for example)
> because if we don't push back I fear we'll end up eventually getting many
> options and hard to support options that will make the tool complex and
> brittle. Maybe I'm too concerned about this, naturally I can't get data
> about clang-format without some form of time machine and travel to parallel
> universes. ;] So far, I've been really happy with the slow growth of
> options though. It feels like we're finding a pretty good balance as we've
> been able to take on a large number of open source coding conventions
> (webkit, to GNU, to the kernel, to LLVM) without too much friction.

I see.

>> However, as people start to use clang-format regularly we will start to
>> have problems with different versions of clang-format formatting
>> differently. (This does not affect companies who always provide the latest
>> version to their developers. But this may not be the common case).
>>
>
> This is I think an interesting question. Lets set aside companies, or
> "providing" versions as that doesn't really matter in the LLVM context or
> the larger open source context.
>
> So, I have three theories here:
>
> 1) It would be harmful to the development and evolution of clang-format to
> resist changing formatting rules this soon. Keep in mind that clang-format
> is a relatively young tool. It hasn't had 10 years to reasonable settle
> into "it works" territory. We're still figuring out how the hell to format
> a decent chunk of C++ code IMO. So I really want to preserve the ability of
> the tool to change and evolve for quite some time longer. I admit that this
> makes it harder to use, but I think it makes it a better tool in the end
> and is worth the cost. Big projects which need stability can (relatively
> easy) pick a version of clang-format and insist upon that. Maybe in 5 or 10
> years we'll be in a better place to get really serious about stability.

There is no need to block development, if there is a good reason for 
change. I just did not see the reason here.

And in fact, clang-format is amazingly stable already. Daniel & Co did a 
great job here.

> 2) I think it's reasonable to ask that developers working on LLVM projects,
> *if* they choose to use clang-format, use a reasonable recent build from
> top-of-tree. I think its healthy for the open source project to eat its own
> dogfood here in a sense (it's a cheap way to help out another part of the
> project). Plus it lets Daniel and others contributing to clang-format to
> very rapidly improve the workflow of LLVM developers, letting them help out
> others in the community. I'll point out that Polly is doing a pretty
> awesome job of this! =D

That's a good point. I still for some reason have the feeling 
maintaining consistency would avoid overhead.

> 3) Even when a developer is using a slightly old version of clang-format,
> as long as they aren't running around reformatting every file in the repo
> on every commit, I suspect that any churn that shows up will be *very*
> minimal.

This change had a larger impact. It will not show up everywhere, but 
there will be patches submitted that follow the old style.

> So, I don't actually see this becoming a serious problem either for
> clang-format in general or the LLVM projects in particular any time soon.
> For the tool in general, as I mentioned in #1, I suspect that in 5 years or
> so we will see a very natural stabilizing trend. For the LLVM projects, I'm
> inclined to wait until we see churn from this become a huge problem, or
> people complain about being unable to dogfood clang-format because of
> having to update it frequently.

My fear is more that it will hold people like e.g. the MIPS guys back to 
even quicker adapt clang-format as an essential component in their 
development progress. It will be adapted nevertheless, but a history of 
stability is a convincing argument never the less.

Cheers,
Tobias