<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>
<div><br></div><div>-- Sean Silva</div></div>