r212591 - clang-format: Revamp function declaration/definition indentation.
djasper at google.com
Wed Jul 9 02:37:40 PDT 2014
On Wed, Jul 9, 2014 at 11:18 AM, Tobias Grosser <tobias at grosser.es> wrote:
> On 09/07/2014 11:01, Chandler Carruth wrote:
>> I significantly prefer the new formatting FWIW.
>> I don't like continuations without indent at all. I'm willing to concede
>> the necessity of them for functions, but for variables it feels quite bad
>> to me.
>> An example of where the old behavior was very confusing for me, let's take
>> the following code:
>> static llvm::cl::opt<whatever> MyLongOptionName(args, more_args, "yadda
>> If we end up (due to the specific balance of string length above) breaking
>> before "MyLongOptionName" we get no indent. But if we break after the "("
>> we get 4 spaces of indent. This is even weirder if your variable doesn't
>> use a "type name(arg, arg);" style of initialization, but instead is "type
>> name = a + b;" as now 'name' would get no indent but 'a' as the start of
>> the second line would get indent. I understand the C++ grammar rules which
>> lead to that scenario, but find it really awkward when reading code.
>> With the new logic, there is one rule for all indentation when breaking a
>> variable declaration across multiple lines: 4 spaces of indent. There is
>> also one rule for indentation when breaking after the return type of a
>> function: no indent.
> I can follow your points and also disliked clang-format inconsistently
> breaking lines in several cases. So seeing work in this area is great.
> If just seemed the commit affects large portions of LLVM, actively try to
> establish a certain coding style and change existing clang-format behavior
> in many cases.
> For such kind of changes, I would prefer an addition to the LLVM coding
> style that explains the reasoning and that ensures that we do once and for
> all agree on a certain style. In this commit we should have the style
What is "such kind of changes"? clang-format takes thousands of similar
decisions that are not written down in the coding conventions, many of them
having a much more significant impact than this change. Writing all of them
down simply doesn't make much sense as nobody would read/remember a style
guide of that length.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits