> 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.

That said ...

> ** Option 2: Contributors each tweak clang-format according to their (in my 
> case strong) bias:

This option seems least-desirable to me. My preference would be that code stays 
formatted as uniformly and invariably as possible; I'm surprised to notice we 
have a .clang-format in the repo, given that it's not being enforced (and 
there's not even a build-system rule to use it, as far as I can see). How would 
people feel about automatic enforcement? i.e. testing a patch fails if 
clang-format has nonempty tree-reformatting to do.

-Graydon

(Who is happy to setq c-indentation-style to anything from Allman to Whitesmith)

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

Reply via email to