r212591 - clang-format: Revamp function declaration/definition indentation.

[Chandler Carruth]

On Wed, Jul 9, 2014 at 2: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
>> 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
> discussion.


I think this is way too heavy weight of a process ... =[ It seems to slow
everything down.

I filed the bug specifically complaining about clang-format's changes (such
as the revisions you cite) and none have argued for clang-format's current
behavior. I know bugs aren't great points of discussion, but unless a bunch
of people show up on this thread saying that they strongly prefer the other
formatting, why not just fix polly and move on? I want to use, dogfood, and
provide feedback on the new behavior, and I can't if we just revert the
change because we're still pondering deeply the really marginal style
implications here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140709/cfde967c/attachment.html>