alt Hacker NewsWhich 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.
Replies
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.
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.
>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.
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].
> 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.
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