gofumpt: It's like gofmt except more strict

Re:gofumpt: It's like gofmt except more strict by KevinMS on Saturday February 11, 2023 @10:01AM (#34752878)

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?

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by layer8 on Saturday February 11, 2023 @10:57AM (#34753446)

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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by bxparks on Saturday February 11, 2023 @11:26AM (#34753698)

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

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by layer8 on Saturday February 11, 2023 @11:57AM (#34754017)

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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by nordsieck on Saturday February 11, 2023 @06:13PM (#34757428)

> 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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by layer8 on Saturday February 11, 2023 @07:40PM (#34758115)

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 just a syntax error.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by mvdan on Saturday February 11, 2023 @11:06AM (#34753523)

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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by mixedCase on Saturday February 11, 2023 @11:58AM (#34754025)

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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by mvdan on Saturday February 11, 2023 @12:22PM (#34754238)

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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by preseinger on Saturday February 11, 2023 @12:29PM (#34754305)

man you can't let snake_case pass code review

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by mixedCase on Saturday February 11, 2023 @11:35AM (#34753794)

> 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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by nordsieck on Saturday February 11, 2023 @12:05PM (#34754089)

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.

[ Parent | on HN ]

Re:gofumpt: It's like gofmt except more strict by preseinger on Saturday February 11, 2023 @12:22PM (#34754241)

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

[ Parent | on HN ]