<div dir="ltr"><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">But I'll address the more meta issue of change in clang-format and options across styles:</div><div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jan 5, 2014 at 5:31 PM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":a8n" style="overflow:hidden">What is the problem with additional options? I did not touch them once yet.<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":a8n" style="overflow:hidden">
<br>
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).<br>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>So, I have three theories here:</div><div><br></div><div>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.</div>
<div><br></div><div>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</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div></long winded ramble></div><div>-Chandler</div></div></div></div>