[PATCH] D32478: [clang-format] Fix AlignOperands when BreakBeforeBinaryOperators is set

Manuel Klimek via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Nov 9 02:55:26 PST 2017


klimek added a comment.

In https://reviews.llvm.org/D32478#920275, @Typz wrote:

> > Sorry for the long response time. I don't see this style rule expressed explicitly in the Skia or QtCreator style guides - is this something that just happens to be done sometimes in the code bases?
>
> This is present in code base. Those project's style guides are not precise enough, and do not document the behavior for this case.
>
> > I have problems understanding the rules from the discussion (as well as the code / test tbh), is there a really concise way to give me the core of the idea?
>
> The case I am trying to address is to really keep the _operands_ aligned after an assignment or `return`, in case line is wrapped *before* the operator.
>
>   int a = b
>         + c;
>   return a
>        + b;
>   
>
> while the current behavior with `Style.AlignOperands = true; BreakBeforeBinaryOperators = true` is to align the wrapped operator with the previous line's operand:
>
>   int a = b
>           + c;
>   return a
>          + b;
>   
>
> In the discussion, it appeared that this behavior is not a error (with respect to the name), but an expected behavior for most coding rules: hence the introduction of a third AlignOperands mode ("AlignAfterOperator"), to handle this new case.
>
> From there the code actually got a bit more complex to support various corner cases (e.g. operators with different number of characters, wrapperd first line, do not unindent more than the enclosing brace...)


Checking out skia and looking at wrapped '+', I see various different formats, and random sampling I've found none so far that would fit your proposed rule. Unless I'm missing something, I'd agree with Daniel; this is not a rule that's widely used, and I'd say reformatting a code base to the clang-formatted variant will not regress readability.


https://reviews.llvm.org/D32478





More information about the cfe-commits mailing list