[dguest]

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.

[TheDong]

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.

[foobarian]

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.

[josephg]

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.

[tremon]

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.

[spockz]

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.

[josephg]

> > programmers care way too much about consistency.

> Indeed, it doesn’t matter too much, as long as it is consistent.

Um, I think you may have missed my point. Why does it always need to be consistent?

The problems you're talking about only show up when someone runs a formatter over the entire file. One answer is, just don't do that.

[lanstin]

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.

[dust-jacket]

I now really want my city to employ local artists to redraw all the street markings.

Chaos, sure, but beautiful chaos.

[dguest]

I really like the street sign analogy.

But in my case it was the other way around. I work in a Kowloon Walled City of code: dozens of intersecting communities with thousands of informally organized but largely content contributors. It looks like chaos, but it works ok.

Code formatting really did feel like a new neighbor declaring "you know what this place needs, better-marked bus lanes!" as though that would help them see the sky from the bottom of an ally or fix the underlying sanitation issues. As you might imagine, the efforts didn't get far and mostly annoyed people.

But as the GP said, it all depends on the culture. If you pick up and move to Singapore you'd damn well better keep your car washed and your code style black.

[swiftcoder]

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

[dguest]

First time I saw this hell was when a junior colleague convinced a rather senior one to use black. Of course senior went bumbling around black-ing every file he touched, including some random thousand-line files in long-lived forks of an established code base. Those files became essentially unmergable from then on.

It was a confluence of a lot of bad design features and blunders and I can't blame the formatter for the mess it caused. So I understand your point but, I'd amend it a bit: version control is the reason many projects require a specific formatting style.

In projects without an explicit style, the number one formatting rule is don't reformat code you didn't touch.

[Cthulhu_]

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.

[speeder]

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.

[odo1242]

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.