Comment by TheDong
2 days ago
On code-formatters, I don't think it's so clear-cut, but rather an "it depends".
For code that is meant to be an expression of programmers, meant to be art, then yes code formatters should be an optional tool in the artist's quiver.
For code that is meant to be functional, one of the business goals is uniformity such that the programmers working on the code can be replaced like cogs, such that there is no individuality or voice. In that regard, yes, code-formatters are good and voice is bad.
Similarly, an artist painting art should be free. An "artist" painting the "BUS" lines on a road should not take liberties, they should make it have the exact proportions and color of all the other "BUS" markings.
You can easily see this in the choices of languages. Haskell and lisp were made to express thought and beauty, and so they allow abstractions and give formatting freedom by default.
Go was made to try and make Googlers as cog-like and replaceable as possible, to minimize programmer voice and crush creativity and soul wherever possible, so formatting is deeply embedded in the language tooling and you're discouraged from building any truly beautiful abstractions.
The biggest problem I ran into without a code formatter is that team wasted a LOT of time arguing about style. Every single MR would have nitpicking about how many spaces to indent here and there, where to put the braces, etc. etc. ad nauseam. I don't particularly like the style we are enforcing but I love how much more efficient our review process is.
Also your eyes are good at seeing patterns. If the formatting is all consistent the patterns they see will be higher level, long functions unintuitive names, missing check for return success; make bad good look bad is the idea. Carefully reading every line is good but getting hints of things to check more deeply because it looks wrong to the eyes is extremely useful.
Personally I think a lot of programmers care way too much about consistency. It just doesn't matter that much if two files use indentation / braces slightly differently. In many cases, it just doesn't matter that much.
Problem is, development doesn't operate on the level of "files". The incremental currency of developers is changes, not files -- and those changes can be both smaller and larger than files. Would you rather see different indentation/braces in different files so that the changeset you're reviewing is consistent, or rather see different indentation/braces in the changeset so that the files being changed remain internally consistent? And what about refactorings where parts of code are moved between files? Should the copied lines be altered so they match the style of the target file?
Point being, "different indentation in different files" is never a realistic way of talking about code style. One way or another, it's always about different styles in the same code unit.
Indeed, it doesn’t matter too much, as long as it is consistent.
People running their own formatting or changes re-adding spaces, sorting attributes in xml tags, etc. All leading to churn. By codifying the formatting rules the formatting will always be the same and diffs will contain only the essence.
1 reply →
I now really want my city to employ local artists to redraw all the street markings.
Chaos, sure, but beautiful chaos.