Here's "bad" code:
important_numbers = {
'x': 3,
'y': 42, # Answer to the Ultimate Question!
'z': 2
}
important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question!
The actual problems in the code I work with are not the spaces at the end of line or imports in non-alphabetic order, it's the 10-line list comprehensions that are so long that they're impossible for me to parse. None of these tools catch that. My place used pylint, flake8, black, ruff -- with hundreds of commits on every change. All that energy could be better spent elsewhere.
It is what it is, everyone gets the same, shut up and work on what matters.
I'm surprised you consider it a lot of energy spent, I tend not to spend any on this, it just runs automatically on my code and I drop out of pretty much every discussions about linting as it's good enough with automated tools.
I also used to work in places where there was no such tools, and there I had to actually spend time discussing and thinking about linting.
Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.
That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind.
However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as in the example above), or an internal joke in the name of a (very long) variable, or vent my frustration in a comment.
My first ten years of writing Python were uneventful; nobody commented about my style and I never commented about others'. With the advent of grammar nazi bots, everyone is supposed to now please them by writing completely bland code, which in my opinion degrades me from a craftsman to a code-monkey. This is dehumanising, in a certain sense.
Which might be more overrated OCD than anything worth it. If you like that, you can add a formatter at the end of the chain or even just when reviewing.
I remember people saying this exact same thing about Python ~20 years ago.
You probably haven't written diverse enough code.
Afterwards it will affect production code everywhere on the planet. :)
And yet, as per the example, the bot force worse linting decisions, and even pushes towards more bugs (e.g. future readers missing the comment intention since it now applies to all 3).
That's because everybody uses linters nowadays, which was the original point.
(I think that in their case it was partially because uniformity made correcting faster.)
I can believe the latter, and I can assure you this was a Big Deal back in the day. There's a reason Go ships with gofmt, and gofmt was somewhat revolutionary for being a built-in "you gotta do it like this" back in the day.
I find that people who argue against automatic linting and formatting tend to be the same that would argue incessantly about style. So much wasted energy, I want none of that.
Also, in your example above, if you put the comment on the line _above_ instead of inline the formatter will most likely do the right thing.