alt Hacker NewsIt'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.
Replies
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.
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.