3 ms·

Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices

Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

maleldil 2y ago
IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style. 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.
- bayindirh 2y ago
  gofmt sorts imports within the block they are in. 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.
  - maleldil 2y ago
    I meant that you could do this with isort in Python or rustfmt with `group_imports = StdExternalCrate` (sadly, not the default), where the imports are automatically separated into blocks, which is basically what you seem to be doing manually. 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.
    - bayindirh 2y ago
      I didn't know that so many people did that so formatters have an option for this. On the other hand, I'm doing this for so long across so many languages, I never thought about it. It consumes no effort on my part. 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.
- Freak_NL 2y ago
  Be careful what you wish for. Sometimes leaving a line stupidly long is better for readability than awkwardly trying to break it up. 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.
  - maleldil 2y ago
    Those would be edge cases where formatting can be turned off if needed. This would require justification during code review. Otherwise, we'd keep the automatic format, with a strong tendency towards the latter. The general benefit of automated formatting outweighs these edge cases.
Defletter 2y ago
Vehemently disagree. I get that go's conventions line up with your own, but when they don't, it's irritating. For example, Dart is finally coming around on the "tall" style (https://github.com/dart-lang/dart_style/issues/1253 https://github.com/dart-lang/dart_style/issues/1253). But why should people be forced to wait for a committee (or some other lofty institution) to change a style convention that then effects everyone using the language? What's the harm in letting people write their code in the "tall" style beforehand? Why must the formatter be so insistent about it?
- anon-3988 2y ago
  > Why must the formatter be so insistent about it? Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?
  - Defletter 2y ago
    Except that a prescriptive formatter with zero configurability is causing this conversation.
    - bayindirh 2y ago
      When you are a solo dev, everything is acceptable. When you're in a group, this can cause friction and cause real problems if people are "so insistent" about their style. 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".
      - Defletter 2y ago
        You are misunderstanding the argument: I am not against prescriptive formatters. By all means, enforce a style convention for your project, I have nothing against that, nor do I understand how you interpreted that from my comment. I am against prescriptive formatters that cannot be configured. This creates the absurd situation, as previously described, where one must appeal to 'The Committee' who decides the style convention for the entire world. This should not be necessary. Nor should you have to surround your code with formatter-disabling comments (assuming the language even supports that) to, for example, use the "tall" style, as previously mentioned. Nor should you have to literally fork the language or its tools to disable the formatter.

maleldil 2y ago

IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style. 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.

bayindirh 2y ago
gofmt sorts imports within the block they are in. 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.
- maleldil 2y ago
  I meant that you could do this with isort in Python or rustfmt with `group_imports = StdExternalCrate` (sadly, not the default), where the imports are automatically separated into blocks, which is basically what you seem to be doing manually. 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.
  - bayindirh 2y ago
    I didn't know that so many people did that so formatters have an option for this. On the other hand, I'm doing this for so long across so many languages, I never thought about it. It consumes no effort on my part. 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.
Freak_NL 2y ago
Be careful what you wish for. Sometimes leaving a line stupidly long is better for readability than awkwardly trying to break it up. 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.
- maleldil 2y ago
  Those would be edge cases where formatting can be turned off if needed. This would require justification during code review. Otherwise, we'd keep the automatic format, with a strong tendency towards the latter. The general benefit of automated formatting outweighs these edge cases.

Defletter 2y ago

Vehemently disagree. I get that go's conventions line up with your own, but when they don't, it's irritating. For example, Dart is finally coming around on the "tall" style (https://github.com/dart-lang/dart_style/issues/1253 https://github.com/dart-lang/dart_style/issues/1253). But why should people be forced to wait for a committee (or some other lofty institution) to change a style convention that then effects everyone using the language? What's the harm in letting people write their code in the "tall" style beforehand? Why must the formatter be so insistent about it?

anon-3988 2y ago
> Why must the formatter be so insistent about it? Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?
- Defletter 2y ago
  Except that a prescriptive formatter with zero configurability is causing this conversation.
  - bayindirh 2y ago
    When you are a solo dev, everything is acceptable. When you're in a group, this can cause friction and cause real problems if people are "so insistent" about their style. 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".
    - Defletter 2y ago
      You are misunderstanding the argument: I am not against prescriptive formatters. By all means, enforce a style convention for your project, I have nothing against that, nor do I understand how you interpreted that from my comment. I am against prescriptive formatters that cannot be configured. This creates the absurd situation, as previously described, where one must appeal to 'The Committee' who decides the style convention for the entire world. This should not be necessary. Nor should you have to surround your code with formatter-disabling comments (assuming the language even supports that) to, for example, use the "tall" style, as previously mentioned. Nor should you have to literally fork the language or its tools to disable the formatter.