Things I beleive:
- If you're picking up on code-style in PRs then your toolchain is backward.
- If you're changing linting rules every month then you're focussed on the wrong things
- It's better to have a consistent style than a perfect style
Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.
Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt.
I'd say that if you're manually formatting stuff with line breaks and spaces, that should have been automated by tooling. And that tooling should run both as a pre-commit hook and in CI.
I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports.
I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort.
golang also aligns variable spacing and inline comments to look them as unified blocks (or a table if you prefer the term) and handles indents. The only thing it doesn't do is breaking lines, which I think acceptable.
My point is that many things we end up doing manually can be automated, so I don't need to care about unsorted or unused imports at all and can rely on them to be fixed without my input, and I don't have to worry about a colleague forgetting to it either.
Also, gofmt not removing the breaking lines and handling groups inside themselves tell me that gofmt is aware of these choices already and accommodates this without being fussy or needing configuration about it, and it's an elegant approach.
If you have five similar statements somewhere with only one exceeding the linter's line length, breaking up that one can lead to code that is harder to parse than just leaving it jutting out by way of an exception to the general rule; especially if it contains some predictable bit of code.
The general benefit of automated formatting outweighs these edge cases.
Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?
Go is a programming language developed for teams. From its syntax to core library to language server to tooling, Go is made for teams, and to minimize thinking. It's opposite of Rust. It's devilishly simple, so you can't make mistakes most of the time.
Even the logo's expression is an homage to this.
So yes, Go's formatter should be this prescriptive. The other thing is, you can continue this conversation till the end of time, but you can't argue with the formatter. It'll always do its thing.
In other words, "computer says no".
Put it this way, if it is technically impossible to develop a car that have the color red, we would not be discussing or entertaining what color the next car should have. It would be red, end of story. It doesn't matter if we like red or not, it just has to be. end of story.
Yes, the code looks awful. end of story.
The fact that Dart's formatter FAQ tells developers who are unhappy with the output to change their code to satisfy the formatter (https://github.com/dart-lang/dart_style/wiki/FAQ#i-dont-like...), rather than allowing developers to tweak the formatter to satisfy their code, is such a huge tell about their mindset. And again, these global styles do not "end the discussion" as people in this thread have asserted. The "tall style" PR (https://github.com/dart-lang/dart_style/issues/1253) refutes that. And that PR has since devolved into bickering and heated demands since its adoption into SDK 3.7.0, since it transforms people's code in ways they dislike and/or find less readable.
Just let people, projects, and organisations enforce their own styles conventions. It's not hard and it shouldn't be controversial.
A healthy toolchain lets a developer separate the Craft from the minutiae.
One interesting thing that happened was the ability to guess who wrote what code purely based on coding style.
The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.