Comment by dguest
2 days ago
It's worse than relinquishing: you get a new voice, that of the person needs an LLM to talk.
I have similar reservations about code formatters: maybe I just haven't worked with a code base with enough terrible formatting, but I'm sad when programmers loose the little voice they have. Linters: cool; style guidelines: fine. I'm cool with both, but the idea that we need to strip every character of junk DNA from a codebase seems excessive.
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.
3 replies →
I now really want my city to employ local artists to redraw all the street markings.
Chaos, sure, but beautiful chaos.
The major reason auto-formatting became so dominant is source control. You haven't been through hell till you hit whitespace conflicts in a couple of hundred source files during a merge...
Code formatting is a bit different though, at least if you're working in a team - it's not your code, it's shared, which changes some parameters.
One factor is "churn", that is, a code change that includes pure style changes in addition to other changes; it's distracting and noisy.
The other is consistency, if you're reading 10 files with 10 different code styles it's more difficult to read it.
But by all means, for your own projects, use your own code style.
I worked on a project where having code formatting used was massively useful. The project had 10k source files, many of them having several thousand lines, everything was C++ and good chunks of code were written brilliantly and the rest was at least easy to understand.
I mean, not sure if this makes sense? The creativity you put into code is about what it does (+ documentation, comments), not about how it’s formatted. I could care less how a programmer formatted their website’s code unless it’s, like, an ioccc submission.