> On Jan 26, 2017, at 11:38 AM, Graydon Hoare <gho...@apple.com> wrote:
> 
> 
>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>> <swift-dev@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.
> 
> It's funny you'd mention this! I often format code that way, not out of any 
> great love of it, but from muscle-memory of living under an old coding 
> guideline somewhere in the distant past claiming that the ugliness of 
> trailing unfinished-binops draws the eye to them and makes the user pay 
> attention. Doug Crockford recommends this style; but of course Don Knuth 
> agrees with you. I don't feel strongly about them as such, but I feel ... 
> anti-strongly, I guess? Like changing that one thing isn't worth a 
> cross-codebase rewrite / merge collision.

I’m not sure who’s recommending what. The above style obscures operators. Does 
anyone disagree with that? A lot of code has been written in that way; I think 
because developers value aesthetics over clarity, or just don’t think about it. 
I care because when something doesn’t stand out, my brain fills in the gaps 
with whatever it expects. For me, that leads to a bunch of silly logic errors.

I need to see it this way:

      if (some_expression->with_calls()
          || another_expression->with(nested_calls())
          && an_even_longer_expression->making_your_eyes->glaze_over())

The need for parens now stands out. Sorry this isn’t a good example. Nested 
expressions would make it much more compelling.

That’s the coding convention we use for Swift code (at least in the stdlib). 
The compiler C++ code is just a hodge-podge.
If anyone actually thinks trailing operators are a good idea for our code base, 
I won’t argue, but I’ve never heard that argument.

BTW- I’m not interested at all in doing a mass reformatting or forcing a 
convention on people. I just don’t want to apply clang-format to every line of 
code I touch without knowing what settings to use.

-Andy
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to