Enum formatting changes - polly automatic formatting verifier

[Chandler Carruth]

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.


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.


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

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

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.

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.


</long winded ramble>
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140105/d9ddb570/attachment.html>