Remove mid-function empty lines after a closing brace about gofumpt

[karalabe]

E.g. Some live code from our repo that uses this style: https://github.com/ethereum/go-ethereum/blob/master/accounts/usbwallet/wallet.go#L443 Here I think any added new line would just make it harder to read.

[karalabe]

Oh, one more instance where I think this is useful. After a inline-defined goroutine launch without any parameters:

go func() {
    // Do something
}()
noNeedForEmptyLineBeforeThis()

[mvdan]

Thanks for filing this issue. I mostly agree with the sentiment, but I worry that this would be too agressive as a rule. When separating chunks of code, I don't think a comment is always enough. It can be enough if the code is simple and short, and if you're used to that style, but in reality not much Go code follows that style.

For example, I opened a random file from the Go standard library, and found multiple instances that don't follow this style, like https://golang.org/src/testing/testing.go#L767. In that case, you'd force the author to either move or add a comment, and I don't think the result would be more readable or more consistent.

One of the driving forces in these rules is to enforce what 95% of idiomatic Go code already follows. While you can argue that this would be something useful for some projects, I think it's not something that's widespread or a net readability win (see above).

[mdlayher]

This is extraordinarily subjective and I don't think there's any consensus that this approach is better or more readable.

I personally find it maddening to try to read a function that is 100 lines long with absolutely no blank lines to break up logical pieces. Whitespace can and should be used to group logical blocks of functionality.

[karalabe]

This is extraordinarily subjective and I don't think there's any consensus that this approach is better or more readable.

Hence why I wrote "opinionated" and "wondering".

I personally find it maddening to try to read a function that is 100 lines long with absolutely no blank lines to break up logical pieces.

Apart from some extreme math heavy code, I don't think any program exists out there that is 100 lines long without a single for loop of if branch. If you do have those however, you already have empty lines on the closing braces.

I personally find it maddening to try to read a function that is 100 lines long with absolutely no blank lines comments to break up explain logical pieces.

[mvdan]

While gofumpt is even more opinionated than gofmt, it tries to follow the already-present standards. I think this is too ambitious and controversial for the tool. And I definitely don't want to add flags :)

@karalabe if you can come up with a rule or heuristic that would keep most existing idiomatic Go code intact, I'm happy to consider it. Otherwise, this is unlikely to happen right now.