> On Jan 26, 2017, at 12:55, Andrew Trick via swift-dev <swift-dev@swift.org> > wrote: > >> >> 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.
I've never had a problem with the trailing operators, and find them mildly more aesthetically pleasing (when not in an if, it makes it clearer what I plan to do with the next line), but I see how they put it in your face in an if. I can change my style. Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
