[swift-dev] Using git-clang-format in the Swift compiler code base.

[Greg Parker]

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev <swift-dev at swift.org> wrote:
> 
> Before I pull in a large PR that "accidentally" reformats a bunch of code, I want to get feedback on how Swift compiler devs plan to use `clang-format`. (BTW, here's the PR https://github.com/apple/swift/pull/6922).
> 
> During the code review, I ran `git clang-format` as part of being a good citizen. There's only one problem with the tool. It rewraps long boolean expressions, hiding those unsightly operators at the end of lines (after all who wants to see those?).
> 
>        if (some_expression->with_calls() ||
>            another_expression->with(nested_calls()) &&
>            an_even_longer_expression->making_your_eyes->glaze_over())
> 
> I don't get involved in style wars, but this is not a style change, it's an objective code quality degradation. It's a demonstrably bug-prone thing to do. It's hurt me too many times in the past, and I'm not happy using a formatting tool that injects future bugs and harms code comprehension.

Counterargument: It's not an objective code quality degradation, it's a style choice that you don't like. 

The first rule of code style is "do as the rest of the code does". 

Trailing binary operators are fine, as long as they are consistent. Mixing leading and trailing operators in the same code base is a greater harm to code comprehension than either one is on its own. Any difference between consistently leading and consistently trailing is small, and not worth the pain of a mass rewrite.

I consider this LLVM and Swift project style to be an objective code quality degradation:
    if (condition)
        single_line_body();

But the first rule of code style is "do as the rest of the code does", so I write my LLVM and Swift code like that.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler