SE-0250: Swift Code Style Guidelines and Formatter

[Paul_Cantrell]

@jawbroken

On 2., nowhere has it been claimed that it preserves all existing “odd whitespace” or similar.

See here:

@Matt_Gallagher

let myModel = MyModel(
   Configuration(
      a
   )
)

…and this reply:

@allevato

swift-format handles that today by respecting existing line breaks that the user has already placed in their code, anywhere that a break would be permitted in an automatic line-wrapping situation. All three of your examples would be valid and remain untouched.

Matt’s “dangling parens” example is IMO appropriate for its context, but certainly not how you’d want most code to look. A formatter that allows it is not a formatter that is going to achieve a high degree of stylistic consistency.

---

@jawbroken

On 1., nowhere has it been implied that the formatter will be a sort of pretty printer for an AST, in the sense that it will take code with arbitrary whitespace variation and unify the presentation.

From the proposal:

2. Developers can move from one codebase to another without incurring the mental load of learning and conforming to a different style or being required to reconfigure their development environment.
3. Developers spend less time worrying about how to format their code and more on the program's logic.
4. Likewise, code reviewers spend less time commenting on code formatting issues and more on its logic and design.

These points all imply the proposal will remove most style decisions. Upvoters in this thread echo these points: no more style decisions, they just happen, you don’t have to think about it, easing cognitive load, projects look the same, no “formatting shock” in an unfamiliar codebase, etc.

Achieving those goals is inconsistent with the tool Tony describes above. If it allows parens like that, there will still be formatting shock.

Either we have a strict formatter and consistent style, or a loose formatter and inconsistent style. That’s strictly a zero-sum game.

In that tradeoff, I tend to err on the side of nuance — but whichever end of the continuum you prefer, we should be clear about where on that continuum this proposal sits. It seems it’s getting support from people who imagine it to exist at both ends.

I’ve said plenty in this discussion at this point, so I’m bowing out now.