Patch for clang-format to allow references and pointers to bind differently

[Chandler Carruth]

On Wed, Dec 4, 2013 at 1:35 PM, Sean Silva <silvas at purdue.edu> wrote:

> Hi Daniel,
>
> 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.
>

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.


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

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.

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.


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

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.

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.

So, why does anyone adopt it? Because get 80% right is *more* than enough.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131205/1142024a/attachment.html>