Hacker News Reader

Comment by KevinMS | Hacker News Reader

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?

View on HN

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

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.

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.

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.

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.

man you can't let snake_case pass code review

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.

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

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.

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

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.

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

Reply on news.ycombinator.com