[PATCH] clang-format: options for spacing template argument lists

[Sean Silva]

On Fri, Oct 25, 2013 at 4:00 PM, Christopher Olsen <chrisaolsen at gmail.com>wrote:

> I am evaluating clang-format and need control over spacing in template
> argument lists to conform to our coding standards.
>
> I've attached a patch that adds new flags to control this spacing.
>  Unittests are also included.
>
> - SpacesInAngles - A<int> vs A< int >
> - SpaceInEmptyAngles - template <> vs template < >
> - SpaceAfterTemplateKeyword - template<typename T> vs template <typename T>
>
> Note that LanguageStandard=Cpp03 overrides SpacesInAngles=false in the
> case of '>>' as in A<A<int> >
>
> Please let me know if there is anything I need to fix for submission.
>

I foresee (and have already run into multiple real use cases) where the
spacing before, after, in between, etc. of many different kinds of tokens
needs to be tweaked. For example:

* multiplicative operators don't have spaces, but additive operators do `a
+ b*c`
* spaces before parenthesized lists in function calls `foo (bar)`
* spaces inside the parentheses of an `if`: `if ( cond ) {`
* "function-like" return: `return(3)`

I think we should try (though it may not be realistic) to integrate this
functionality in a way that covers the different use cases and makes them
interact in a consistent and understandable way; otherwise we will just end
up growing a forest of not-easy-to-discover options that don't have very
good coverage of the configuration space for the next project. For example,
adapting clang-format to the OP's project coding standards requires adding
3 new options; is there a realistic upper bound on the number of such
options that we will need in order for clang-format to support, say, 1000
different projects from 50 different companies/open-source communities?

One possibility that I can imagine (although I don't know how feasible it
is) is to ship another tool (or more likely keep it under an option to
clang-format) which does a "one time" analysis to determine a set of
parameters that will conform with a given sample source file (or files) and
emits a configuration file. This analysis could work with a larger (but
very consistent and well-defined) "plumbing" configuration space that
essentially parameterizes the "guts" of clang-format (such as
`spaceRequiredBefore`, `spaceRequiredBetween`, `splitPenalty`, etc.) in a
data-driven way.

On the other hand, I think it has been put out there before is that one of
the benefits of clang-format is to help "standardize" to some extent on a
common subset of style options, and so providing too-fine-grained support
for "tweaking" the output might be undesirable from such a perspective. On
the other hand, if clang-format wants to "dominate the world", it can't
impose arbitrary changes on a project's coding style. A poignant question
is "is it a goal for clang-format be able to conform with
more-or-less-arbitrary styles without requiring requiring the users to get
involved with clang-format development?", but I can't speak as to the
answer.

Daniel, what do you think?

-- Sean Silva


>
> Thanks!
> Chris
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131025/6c693ca2/attachment.html>