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

[Daniel Jasper]

@Sean:
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).

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

@Ben:
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.

@Sean, @Ben:
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.


On Wed, Dec 4, 2013 at 10: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.
>
> 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.
>
>
>
> 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..
>
> -- Sean Silva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131204/419025b9/attachment.html>