[PATCH] D14484: Formatting constructor initializer lists by putting them always on different lines

[JVApen via cfe-commits]

JVApen added a comment.

In http://reviews.llvm.org/D14484#284767, @djasper wrote:

> Please read
>  http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
>
> Does your style option qualify?




- Is it used by a project of significant size? Yes, we use the same style at work, where I try to get this used by about 70 developers. (Which I consider already dozens of contributors) Though it is also the same style I learned at school.
- Does it have a publicly accessible style guide? Yes, it's both an accepted by the Google Style guide <https://google.github.io/styleguide/cppguide.html#Constructor_Initializer_Lists> as Ubuntu Unity <http://unity.ubuntu.com/wp-content/uploads/2012/03/cppguide.html?showone=Constructor_Initializer_Lists#Constructor_Initializer_Lists>, which do not state that you have to use the compact form. Further more the graphisoft <http://download.graphisoft.com/ftp/techsupport/documentation/developer_docs/AC15/CPPStyleGuide/CPPHtmlLibrary/main.HTML#Methods> styleguide doesn't appear to allow the condensed form.
- Does it have a person willing to contribute and maintain patches? Maybe, I currently don't believe I'm familiar enough with the code to maintain it. Though without putting it out here (e.g. LLVM community) the answer will definitely be no. Furthermore, beside the 2 lines in TokenAnnotator.cpp, this style does not differentiate from the current implementation.

Though since you are the/a maintainer of this code, you are more qualified to give a final answer on this question.

Regardless, even if you don't want this patch upstreamed, I like to understand the codebase better as well as the considerations which lead to certain decisions for code changes. (See also the uncertainties I listed in the original post) Which at least will make my local changes similar to what they would be in case you would allow an upstream of them.


Repository:
  rL LLVM

http://reviews.llvm.org/D14484