Comment by Majestic121
2 days ago
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.
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.
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.
Waiting patiently for the other person to produce a post hoc rationalization about why everybody’s code looking different is in fact a good thing
24 replies →
>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.
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.
The value isn't just in the lack of discussion, but in amplifying the signal to noise ratio of diffs. with ruff or gofmt or whatever, it’s pretty much guaranteed that a change of code is an intentional part of the proposed change. with multiple authors with variable code styles touching the same project, there is a much higher chance of a diff containing lines that preserve semantics but change the code.
There's a ton of variation in golang code, as gofmt is not opinionated enough. As evidenced by the existence of golines[0] or gofumpt[1].
0: https://github.com/golangci/golines/
1: https://github.com/mvdan/gofumpt
> 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
I remember people saying this exact same thing about Python ~20 years ago.
Is that really a problem that needs solving though? The easiest way to not spend time bikeshedding is to just not bikeshed. Don't make guidelines. Don't run tools to check them. Don't comment on them in PRs. None of it matters.
3 replies →
Using a consistent string delimiter has value: if you search for ['foo'] you will find all instances of the string foo. With inconsistent delimiters, you better have a single canonical 'foo' in your project or you're going to run into problems.
The inverse is also true (speaking from PHP, I'm not 100% familiar with Python semantics). If we use '' where appropriate, then we know absolutely no escaping and no interpolation is done. That has value. If we use "" for everything, then we have to examine the string for interpolation or for escaping.
See if you know where this leads before clicking on it: https://xkcd.com/208/
4 replies →
When a string contains strange characters, how do you enforce the single consistent delimiter?
You probably haven't written diverse enough code.
I would hate to work on that codebase. We learn to parse code more quickly over years of looking at code written with the same conventions and style. There’s a reason why Google are so serious about following their style guides.
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. :)
This is the way, and why I wrote https://pypi.org/project/ssort/. Unfortunately you need to follow it up with shameless self-promotion or it doesn't work.
>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.
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).
the claim we are arguing here is not that “linters never make mistakes” it is that “linters are generally beneficial and avoid mostly useless debates we previously spent an inordinate amount of time on” Most linters have an escape hatch for exactly this which is usually a one line disable comment
There is no point discussing these minutia, ever. Just ban discussing them in PRs and then you don't need an opinionated bot rife with false positives to "fix" them.
And yet, a new argument surfaces about whether or not the linking should take place. Some people just like to argue :)
Dunno, now the workflow is like agent makes code changes, ruff complains, agent fixes complaints at the cost of code bloat, agent makes a PR, another agent reviews the PR, agent makes changes, PR is approved and merged. Nobody reads PRs anymore with the agentic development velocity.
> Nobody reads PRs anymore with the agentic development velocity.
Tokens are burnt, that's the most important part. And with more of the generated shitty code there will be more tokens spent in the future.
I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.
It's not by accident that tabs vs spaces is one of the stereotypical great debates in programming.
I've never seen this debate take place outside of internet forums, almost always as a joke. It's been about 15 years since I even remember it coming up much as a joke, frankly.
4 replies →
> something that predates my career
That's because everybody uses linters nowadays, which was the original point.
I'm not convinced.
I've made comments if the formatting is egregious enough. This is a "bigger problem" in not-python, languages without significant whitespace. You can truly write some horrifying code that will compile just fine.
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.)
At work? School isn't really representative.
8 replies →
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.
I think the culture has just shifted. I haven't even sniffed a whiff these conversations since roughly 15 years ago. I've never, ever seen them at work.
1 reply →
> this seems like a made up problem or something that predates my career
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.
What is "back in the day" here? I've been in this field for like 16 years.
1 reply →