Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.





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

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.

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.

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


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


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




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: