<div dir="ltr">@Sean:<div>Arguing about possibly beautiful futures bordering on fairy tales is even more pointless than arguing about style. If you have concrete plans to plan and execute a re-implementation of clang-format or its style configuration part, knock yourself out. I am happy to provide input as best I can. I won't have time to fundamentally redesign any part of clang-format in the foreseeable future. And its not like there are many other contributors (there are Manuel and Alex of course, but they have the same constraints as I do).</div>

<div><br></div><div>--detect-style will be nice, but it is going to be significantly more effort than you might think. For many of the style configuration flags, the signal to noise ratio is actually not that high in any codebase I have seen. Yes, you can take a majority vote, but in any codebase with a significant number of developers that might be the wrong thing to do (e.g. look at how much different feedback you got on your template<> always on its own line discussion). I do believe that this is an important feature that we should work on. But until I see this working in practice, I am hesitant to make decisions based on it.</div>

<div><br></div><div>@Ben:</div><div>There simply are styles that I don't consider support-worthy. Yes, this is personal, but the line has to be drawn somewhere. E.g. imagine somebody would say "I want two spaces before every even integer literal" or "I need an option to align all semicolons" or "I really want my code to be right-aligned". I am not saying your style essentially falls into this kind, but it is my first reaction to it (and your arguments about different usage patterns don't really change that). I certainly don't want more people to adopt this style. However, it might be my ignorance because I might not have worked on enough projects to see that this is actually a common style. Get me any kind of numbers. How many projects are there that use this style? Is there a publicly accessible coding style that says that this is a good idea? Basically any reference at all might useful. If it just your codebase and you absolutely need clang-format to support this, fix the harder problems first. It would be bad if we get this into clang-format and we can't fix your other concerns so that in the end nobody uses this style.</div>
<div><br></div><div>@Sean, @Ben:</div><div>Another approach to this problem (which might be sort of half-way to what Sean is suggesting) is for clang-format to provide hooks for extensions. For example after annotating all the tokens, clang-format could call some custom function provided by the user that runs over all the tokens and adjust stuff like whether or not to put a space before a certain token. That way a user could implement a lot of stuff that falls into the not generally support-worthy category.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 10:35 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Daniel,<div><br></div><div>It seems really counterproductive for the author of a formatting tool to argue with his users about their style choices (even to the point of arguing about leaving pointer initialized/uninitialized). Much better to work on coming up with a design that can support their use case.</div>

<div><br></div><div>Maybe a possible solution is to move to a design where --detect-style is the primary way of generating config files and a style is a richer and more customizable notion than just an ad-hoc set of hard-coded flags (that interact in ad-hoc ways and each constitute a sizeable maintenance burden).</div>

<div><br></div><div>In fact, I think that getting to the bottom of what constitutes a "style" (and some general way to represent that) is probably half the battle. This is like what Knuth had to do when designing TeX (devising the boxes and glue model for representing page layout). The boxes and glue model is probably fairly close to what clang-format needs, although clang-format needs some sort of external declarative rule-based way to specify where and what kind of "glue" needs to be inserted; "boxes" would likely be formed by the pseudo-C++ parser. clang-format also has a more context-sensitive aspect, which could be addressed by using the underlying pseudo-C++ parser to inject "annotation tokens" into the token stream (e.g. "starting template parameter list" could be an annotation token) or maintain a stack of "contexts" (e.g. "inside template parameter list" could be a context), that can then play a role in rule-matching. Also, there's the added wrinkle of designing it in such a way that there is a tractable way to optimize it to match a given style.</div>

<div><br></div><div><br></div><div><br></div><div>In a large number of cases, even a single deviation from the local coding style is likely to fully block adoption of clang-format. It's a classic catch-22: if they knew how great clang-format would be for their codebase, then they would probably be willing to go through the politics to change some small aspect of the company/project/game studio coding style, but without having a critical mass of developers using it, it's unlikely that anybody will jump through those hoops to appease a new tool, but if clang-format doesn't comply with their coding standard, nobody can really start using it fully (they always have to check if it gets it right and fix where it messes things up, which sort of defeats the purpose), etc..</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-- Sean Silva</div></font></span></div>
</blockquote></div><br></div>