3 ms·

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

by o11c 11mo ago

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 11mo ago
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 11mo ago
  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 11mo ago
    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 11mo ago
> * 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.
zahlman 11mo ago
> * 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.
seanssel 11mo ago
> 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?
- deleted 11mo ago
  [deleted]

by o11c 11mo ago

layer8 11mo ago

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 11mo ago
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 11mo ago
  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 11mo ago

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

zahlman 11mo ago

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

seanssel 11mo ago

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

deleted 11mo ago
[deleted]