Comment by maratc
2 days ago
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.
2 days ago
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
My argument is more to the tune of "everybody’s code looking slightly different is not a problem in practice as long as I can read and understand it."
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.
15 replies →
Can you not read code if it uses single vs double quotes?
6 replies →
That's exactly what a good cogwheel in the machine would say
>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.
Historically, yes. At some point, one person who likes to work with narrow terminal windows gets fed up with long lines and starts reformatting stuff as they go. Another person with a widescreen editor hates looking at code clustered around the left edge of the screen gets fed up and starts reformatting stuff as they go. It's just a mess. You end up with PRs where it's hard to see the 3 things that changed because it contains 200 lines of "my IDE would prefer to format things this way instead".
I have never seen this not happen, barring using autoformatters. I think Go and Rust have had great success avoiding all these dumb arguments by having built-in opinionated formatters from nearly the beginning.
2 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/
So your argument is that your freedom to use whatever string delimiter you want (remember that ''', """, ` and even weird unicode glyphs are valid in many languages) is worth forcing other engineers on the team to know all valid string delimiters and remember to use the right regex to account for all possible weirdo choices?
3 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.