Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gofumpt: A stricter gofmt

github.com

Post reply on HN
Print view View original

11–20 of 93 posts

Re: Gofumpt: A stricter gofmt

#11

Post by fivre »

rickette wrote: post #5

gofmt being the official tool avoids bikeshedding over formatting rules. Diverging from the default seems like a step backwards, doesn't it?

very much so imo. the standard formatter is one of the things go very much does right

my protests against requiring this, as additional friction for our OSS contributors especially, unfortunately fell on deaf ears. unfortunately i just don't have the energy to beat my more pedantic coworkers over the head with the notion that if these additional formatting rules are that important to them they need to do the legwork to pull them into mainline gofmt

nah, that's actual work. an additional hurdle in the dev environment for some random formatting things that nobody will ever notice though, you can enforce that in a few lines of CI scaffolding, so into the checks it goes

Re: Gofumpt: A stricter gofmt

#13

Post by saurik »

FooBarWidget wrote: post #10
akdor1154 wrote: post #4

Anyone know if the following exists? Gofmt/gofumpt, but as a special case, formats if err != nil { return err } on a single line. Not trolling, genuinely interested.

I've found that it's almost always a good idea to return fmt.Errorf(...), adding context to the error. Otherwise error messages are too generic and it's hard to figure out what's actually wrong. Then it doesn't fit on a single line anymore.

It doesn't? It is only a tiny tiny bit longer than the fmt.Errorf() by itself, which is surely one line, right? The key thing is to then have your syntax highlighter set up to specially handle these lines, to help you 1) know that they are there, 2) know that they are structured correctly, and 3) ignore them (which is safe now that you can see it exists and is in the right format). Unless you set these up as one line, your Go code gets littered with 3x (or even 4x if you add a blank line after each block, which starts to feel better) as much error handling lines as non-error lines.

Re: Gofumpt: A stricter gofmt

#14

Post by therein »

FooBarWidget wrote: post #10
akdor1154 wrote: post #4

Anyone know if the following exists? Gofmt/gofumpt, but as a special case, formats if err != nil { return err } on a single line. Not trolling, genuinely interested.

I've found that it's almost always a good idea to return fmt.Errorf(...), adding context to the error. Otherwise error messages are too generic and it's hard to figure out what's actually wrong. Then it doesn't fit on a single line anymore.

I enjoy errors.Wrap/Wrapf too.

Re: Gofumpt: A stricter gofmt

#15

Post by cesnja »

akdor1154 wrote: post #4

Anyone know if the following exists? Gofmt/gofumpt, but as a special case, formats if err != nil { return err } on a single line. Not trolling, genuinely interested.

The default gofmt doesn't format this way, so any tool implementing this would not be compatible.

Re: Gofumpt: A stricter gofmt

#17

Post by [deleted] »

fivre wrote: post #11
rickette wrote: post #5

gofmt being the official tool avoids bikeshedding over formatting rules. Diverging from the default seems like a step backwards, doesn't it?

very much so imo. the standard formatter is one of the things go very much does right my protests against requiring this, as additional friction for our OSS contributors especially, unfortunately fell on deaf ears. unfortunately i just don't have the energy to beat my more pedantic coworkers over the head with the notion that if these additional formatting rules are that important to them they need to do the legwork…

[deleted]

Re: Gofumpt: A stricter gofmt

#18

Post by parhamn »

Am I understanding correctly that: gofmt(gofumpt(code)) == gofumpt(code)?

If so, I don't get the negativity in these comments centered around diverging from gofmt. A developer could make any of the decisions that gofumpt made.

Re: Gofumpt: A stricter gofmt

#19

Post by mseepgood »

parhamn wrote: post #18

Am I understanding correctly that: gofmt(gofumpt(code)) == gofumpt(code)? If so, I don't get the negativity in these comments centered around diverging from gofmt. A developer could make any of the decisions that gofumpt made.

Yes, that's how it works.

Re: Gofumpt: A stricter gofmt

#20

Post by watt »

Seems a lot of these rules focus on removing empty lines. I find empty lines let the code "breathe" a bit.

Without them, it's a massive wall of text, sometimes. Well, often times.

It's interesting you can address the "wall of text" problem in 2 ways.

1) Get IDE strategically insert vertical whitespace, for example right after function definition, and before function body. It does not need to be a full empty line, half of line height would do.

2) Or other way around, if you have an empty line before function body starts, IDE could narrow the height a bit, because this does not need a full-size empty line. Actually I wonder if there are IDEs around that play with variable line height for empty lines.

The above would allow folks who feel they are starved for vertical space to condense the code more, without impacting others who feel they have plenty of vertical space, and would like to break the "wall of text" with white space breathers.

Currently Intellij (GoLand) will strategically fold the `if / return err` pattern that Go code is littered with, so the whole "keep it on single line" point is moot for somebody using an advanced IDE that automatically renders the code in way to reduce visual clutter.

Post reply on HN