The amount of fascination that people have with these "grammar nazi" bots -- some of them implementing completely arbitrary "rules" and some of them disagreeing with others on what "good" Python code should look like -- doesn't stop to amaze me.

Here's "bad" code:

     important_numbers = {
        'x': 3,
        'y': 42, # Answer to the Ultimate Question!
        'z': 2
    }

Here's what "good" code should look like:

    important_numbers = {"x": 3, "y": 42, "z": 2}  # Answer to the Ultimate Question!

Which completely misses the writer's intent. But did you notice that there are two spaces before the pound now? Also, the quotes are now double because apparently it's somehow more kosher! So much improvement!

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.

▲ Majestic121 an hour ago | parent | next [-]

The point of the "grammar nazi" bots is to focus on the actual problems: if a bot is deciding about linting, you don't have to waste brain power to discuss it in PRs.

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.

▲

Stitch4223 5 minutes ago | parent | next [-]

Even better: if someone feels like the syntax must be different, they can pick it up at a centralized repository with more people that specialize in syntax.

Afterwards it will affect production code everywhere on the planet. :)

▲

maratc an hour ago | parent | prev | next [-]

In my previous place, discussions on coding style were forbidden in PRs. It worked just fine.

Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.

	▲	dewey 34 minutes ago \| parent [-]
		Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them. 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.

▲

insanitybit 44 minutes ago | parent | prev [-]

I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.

	▲	pdpi 41 minutes ago \| parent \| next [-]
		It's not by accident that tabs vs spaces is one of the stereotypical great debates in programming.
	▲	microtonal 41 minutes ago \| parent \| prev \| next [-]
		These used to happen all the time. In one (otherwise great) programming course in university you would even get points subtracted if you did not follow the lecturer's preferred style. (I think that in their case it was partially because uniformity made correcting faster.)
	▲	time0ut 32 minutes ago \| parent \| prev [-]
		Silicon Valley (the TV show) memed about it with its tabs vs spaces bit. It used to be a thing for sure. It has been a good 10 or 15 years since I had such a discussion. Automated linting and formatting tools largely killed it in my experience.

▲ jbvlkt an hour ago | parent | prev | next [-]

Those tools actually save team energy. Without them any programmer has different opinion on formating, code quality, what is readable etc. You can discuss it endlesly or you can just use ruff.

▲

maratc an hour ago | parent | next [-]

We can replace the endless and useless discussion on how to format code with an endless and useless discussion on what linting tool to use.

Another option would be to leave both topics alone and go on with our lives, improving the product, fixing bugs, implementing new features, and generally giving customers a better product and shareholders more value, while respectfully agreeing to disagree on the issues of style.

	▲	Hendrikto 6 minutes ago \| parent \| next [-]
		> We can replace the endless and useless discussion on how to format code with an endless and useless discussion on what linting tool to use. That is why gofmt is so great. As the saying goes: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
	▲	jbvlkt 29 minutes ago \| parent \| prev [-]
		People tend to use tools set up in CICD and/or precommit. Without rules everyone uses their tool and is unwilling to compromise. Even if they are willing it is hard to setup tools to do exactly what you want. Default configuration is always the way.

▲

LaGrange an hour ago | parent | prev [-]

Gods forbid I talk to people I work with, learn their preferences, and figure out the way we can accommodate each other. Sounds like such a waste of energy. It’s so much better if we all acquiesce to the preferences of some people neither of works with!

	▲	jbvlkt 35 minutes ago \| parent [-]
		You can still talk to them about more important problems than placement of collons and closing bracket.

▲ wodenokoto 37 minutes ago | parent | prev [-]

It’s because you forgot a comma after the last item. If you had kept that the items wouldn’t have been compacted (at least in black, I’ve stopped linking my code because it breaks intends of formatting more often than it helps)