<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 4, 2013 at 1: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></blockquote><div><br></div><div>It may seem counterproductive, but in the course of developing clang-format I have seen Daniel and others *consistently* find that an initial formatting request can only effectively be understood by digging into the motivation behind that formatting style. I'm not saying we should spend too much time on it, but I hesitate to call it actually counterproductive.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<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></blockquote><div><br></div><div>All of these comments echo those that took place during the early days of designing and building clang-format. I don't mean to dismiss them as "done" quite the opposite. They are the crux of what makes this problem hard.</div>
<div><br></div><div>However, Daniel picked a design, and demonstrated that it worked *very very* well. If you want to go back and try different designs, I think you will have to produce the working implementation or prototype of that design which demonstrates that it works better.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<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..<br>
</div></div></blockquote><div><br></div><div>I really want to jump on this issue, as I do not believe it to be true in theory, and I have empirical data that it is not true in practice.</div><div><br></div><div>We cannot ever build a tool which avoids even a single deviation from the local coding style, no matter how much configuration we add. This is a fact of life: programmers are far more clever at devising code formatting styles than clang-format will be. Having worked with Daniel as he deployed this tool to literally thousands of users working across 10s of largely independent bodies of code, we have never even come close to this goal.</div>
<div><br></div><div>So, why does anyone adopt it? Because get 80% right is *more* than enough.</div><div><br></div><div>Fundamentally, clang-format is built on the premise that that code want consistent formatting more than clever formatting. This lets them train themselves in how to read the code formatted in that way. So in many cases, there is already a *huge* carrot to get adoption of clang-format. We have seen this consistently in talking to hundreds of users and learning what their experience was using clang-format. If we can get clang-format to handle 80% of the world's coding styles to roughly 80% accuracy, I'll be overjoyed. But we should keep a firm eye on the complexity of the tool itself and not blindly go after adhering to more and more conventions.</div>
</div></div></div>