> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev <[email protected]>
> 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.
>
> When the LLVM coding style was originally ratified, this aspect was left up
> to individual preference and didn't get any discussion AFAIK. I think
> clang-format then ended up with a `BreakBeforeBinaryOperators: None` style
> out of sheer inertia.
>
> So, how should I use clang-format on Swift compiler code? Vote please.
>
> ** Option 1: Add a simple configuration option to swift/.clang-format:
>
> 1a. BreakBeforeBinaryOperators: All
>
> 1b. BreakBeforeBinaryOperators: NonAssignment
>
> I have absolutely no preference between 1a and 1b. It's purely style.
>
> 1a:
> SomeLongTypeName someLongVariableName =
> someLongExpression();
>
> 1b:
> SomeLongTypeName someLongVariableName
> = someLongExpression();
1b sounds good to me.
>
> ** Option 2: Contributors each tweak clang-format according to their (in my
> case strong) bias:
>
> My own command line:
> 2a. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: All}"
> 2b. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators:
> NonAssignment}"
>
> ** Option 3: Don't bother using clang-format.
>
> Let emacs do its indentation thing. Embrace idiosyncrasies in the code base.
>
> -Andy
> _______________________________________________
> swift-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
