[o11c]

There are 3 major problems with automated code formatters:

* Handling of multiple newlines to break sections, or none to group related functions (e.g. a getter with a setter). Sometimes it's even best to move functions around for better grouping.

* They don't factor out an expression into a separate variable.

* They destroy `git blame`. This one is avoided if the tooling has always enforced formatting.

[layer8]

Regarding the second one, a formatter shouldn’t be changing the AST. At most inserting parentheses/braces/semicolons for clarity, which doesn’t change the AST structurally (or, depending on one‘s definition of “AST”, doesn’t change it at all).

[o11c]

Perhaps, but it is absolutely relevant. Most of the horrible formatting results are due to the formatter trying really hard when the user really should introduce a variable.

[layer8]

True, formatters can only do so much. The purpose formatters is not to guarantee readable code, but to guarantee uniform code. Use of a formatter doesn’t relieve a programmer from taking care that the code is readable. But it ensures that everyone is using the same formatting conventions.

[dragonwriter]

> * They don't factor out an expression into a separate variable.

That's...not formatting, and there's probably no good deterministic rule for when to do that, anyhow.

[seanssel]

> They destroy `git blame`

How is this a problem with auto formatters? This is completely on the person/team, not the tool. Even if the repo doesn’t enforce on pre-commit or something, don’t most formatters have the option to only format lines you’ve actually changed?

[zahlman]

> * They don't factor out an expression into a separate variable.

* They implicitly enable people to write deeply nested code that lacks such factoring, without feeling like anything has gone wrong.