4 ms·

Hate the padded block rule with a passion. Maybe I'm weird but one of the greatest things about gofmt is that it doesn't murder "padded blocks", like so many f

Hate the padded block rule with a passion. Maybe I'm weird but one of the greatest things about gofmt is that it doesn't murder "padded blocks", like so many formatters out there. For example, given this func main() { fmt.Println("a") fmt.Println("b") fmt.Println("c") fmt.Println("d") } gofmt will simply collapse the double line in the middle. However, this tool will do this func main() { fmt.Println("a") fmt.Println("b") fmt.Println("c") fmt.Println("d") } How is having chunks of code smashed into the tops and bottoms of a blocks good for improving readability? Why should the visual relationship between and main() and "a" be stronger than between "b" and "c" if the author doesn't want it?

layer8 4y ago
As a non-Go developer, IMO the mistake is not putting the opening brace on its own line, for the “smashed into the top” reason you mention.
- bxparks 4y ago
  As far as I understand, that's a consequence of the automatic insertion of trailing semicolon by the lexer, not a decision by gofmt. It's explained here: https://go.dev/doc/effective_go#semicolons https://go.dev/doc/effective_go#semicolons
  - layer8 4y ago
    I see. That doesn’t seem very sensible in potential-beginning-of-block contexts, in particular in the if case where an implicit empty statement is deduced after the condition.
    - nordsieck 4y ago
      > That doesn’t seem very sensible in potential-beginning-of-block contexts, in particular in the if case where an implicit empty statement is deduced after the condition. Are you referring to C style if statements where you can elide the braces? In go the braces are mandatory, so I don't think that really applies.
      - layer8 4y ago
        I was referring to the Go documentation linked above: > One consequence of the semicolon insertion rules is that you cannot put the opening brace of a control structure (if, for, switch, or select) on the next line. If you do, a semicolon will be inserted before the brace, which could cause unwanted effects. I was assuming that the “unwanted effects” are not simply a syntax error.
mvdan 4y ago
I hadn't really considered that people might want to do this. From experience reading and writing Go code for ~8 years at multiple companies, the only times I've seen leading or trailing empty lines in blocks have always been either inconsistent or unintentional, and usually both. Are there Go codebases that stick to the formatting you show, out of curiosity? Either way, please file a bug. Perhaps others can chime in there if they also use the same style.
- mixedCase 4y ago
  I've seen this once across many Go codebases, it was someone who even a year in writing Go still refused to consistently name constants and global variables without snake_case, among other similar behaviors. Support for allowing configuration of such a thing would be a misfeature if I was to be asked.
  - mvdan 4y ago
    gofumpt will never have formatting knobs, following gofmt's design. But if one of gofumpt's rules forbids a style which is reasonable even if it's not very popular, we might want to make the rule more conservative or remove it entirely.
  - preseinger 4y ago
    man you can't let snake_case pass code review
mixedCase 4y ago
> How is having chunks of code smashed into the tops and bottoms of a blocks good for improving readability? How is having a random newline at the top and bottom where there is already a clear separation between function signature and implementation via braces and the guide of the first indentation, helping readability? All it does is steal valuable vertical space away from things that matter.
nordsieck 4y ago
IMO, vertical space is a precious resource in software development. It shouldn't be squandered without clear and compelling reason. I'm not saying that there's never a reason for to have extra blank lines. But your example isn't it.
preseinger 4y ago
there is no "visual relationship" between main and a, indentation differentiates blocks, empty lines at block begin/end serve no purpose, please stop doing this

layer8 4y ago

As a non-Go developer, IMO the mistake is not putting the opening brace on its own line, for the “smashed into the top” reason you mention.

bxparks 4y ago
As far as I understand, that's a consequence of the automatic insertion of trailing semicolon by the lexer, not a decision by gofmt. It's explained here: https://go.dev/doc/effective_go#semicolons https://go.dev/doc/effective_go#semicolons
- layer8 4y ago
  I see. That doesn’t seem very sensible in potential-beginning-of-block contexts, in particular in the if case where an implicit empty statement is deduced after the condition.
  - nordsieck 4y ago
    > That doesn’t seem very sensible in potential-beginning-of-block contexts, in particular in the if case where an implicit empty statement is deduced after the condition. Are you referring to C style if statements where you can elide the braces? In go the braces are mandatory, so I don't think that really applies.
    - layer8 4y ago
      I was referring to the Go documentation linked above: > One consequence of the semicolon insertion rules is that you cannot put the opening brace of a control structure (if, for, switch, or select) on the next line. If you do, a semicolon will be inserted before the brace, which could cause unwanted effects. I was assuming that the “unwanted effects” are not simply a syntax error.

mvdan 4y ago

I hadn't really considered that people might want to do this. From experience reading and writing Go code for ~8 years at multiple companies, the only times I've seen leading or trailing empty lines in blocks have always been either inconsistent or unintentional, and usually both. Are there Go codebases that stick to the formatting you show, out of curiosity? Either way, please file a bug. Perhaps others can chime in there if they also use the same style.

mixedCase 4y ago
I've seen this once across many Go codebases, it was someone who even a year in writing Go still refused to consistently name constants and global variables without snake_case, among other similar behaviors. Support for allowing configuration of such a thing would be a misfeature if I was to be asked.
- mvdan 4y ago
  gofumpt will never have formatting knobs, following gofmt's design. But if one of gofumpt's rules forbids a style which is reasonable even if it's not very popular, we might want to make the rule more conservative or remove it entirely.
- preseinger 4y ago
  man you can't let snake_case pass code review

mixedCase 4y ago

> How is having chunks of code smashed into the tops and bottoms of a blocks good for improving readability? How is having a random newline at the top and bottom where there is already a clear separation between function signature and implementation via braces and the guide of the first indentation, helping readability? All it does is steal valuable vertical space away from things that matter.

nordsieck 4y ago

IMO, vertical space is a precious resource in software development. It shouldn't be squandered without clear and compelling reason. I'm not saying that there's never a reason for to have extra blank lines. But your example isn't it.

preseinger 4y ago

there is no "visual relationship" between main and a, indentation differentiates blocks, empty lines at block begin/end serve no purpose, please stop doing this