Good. Go deserves this. Before gofmt, programmers were allowed to have accents. Teams were allowed to decide their preferred style. Since gofmt, we "avoid bikeshedding" by disallowing the developer from adding any value via formatting. Dozens of languages that are far more sophisticated than Go have adopted this boneheaded approach (typical Go philosophy) in the years since gofmt appeared. It'll be a while before I r…
I personally am looking forward to the go tool replaces `go run` etc. for a version that makes additonal whitespace and misalignment into a compiler error!
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.
Does gofmt have a problem with error handling on one line?
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…
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.
See also: interfacer - Automatically Suggest Interface Types in Go https://github.com/mvdan/interfacer https://news.ycombinator.com/item?id=11397905 (9 comments) shmfmt - A shell parser, formatter, and interpreter with BASH support https://github.com/mvdan/sh (Submitted often but not yet discussed) --- /me whispers: Hint: You could be that guy [1] (or gal, they, it, etc): /submit shmfmt Feel free to leave a link to y…
oh awesome thanks for sharing! shfmt works very well so far. i've been using acme for a few weeks and need every formatter i can get :) https://9fans.github.io/plan9port/man/man1/acme.html
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, hal…
I agree that empty lines can help. I've been careful to only remove empty lines which, in my opinion, don't help when structuring the code or making it more readable. If you have examples where gofumpt is being a bit too aggressive, I'd like to hear about them. I've corrected, and even removed, some of gofumpt's rules in the past thanks to user input.
I use gofumpt for all my go code (have been for at least two years), and I use empty lines for structure. Out of the tens to hundreds of thousands lines written, I don’t recall a single instance where an intentional empty line was removed. I doubt gp’s comment is based on experience. Another giveaway is the “seems” at the very beginning.
Ye. This is agile deep down removing the fun from programming with all its toxic processes. Programmers are the worst when it comes to forcing their dogmatic believes on others.
This, I really don't get why people want to enforce uniformity, a room filled with people with exactly the same accent is a boring room. Most teams I've worked on slowly converge to a "house style" in any case, and if you're on the team, your personal preferences are a part of that. Not some committee.
you know that work is supposed to be boring, right?
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.
github.com/pkg/errors is dead — it’s been archived for a long time, and doesn’t incorporate go 1.20’s multi-error wrapping. Better switch to fmt.Errorf in new projects going forward.
See also: interfacer - Automatically Suggest Interface Types in Go https://github.com/mvdan/interfacer https://news.ycombinator.com/item?id=11397905 (9 comments) shmfmt - A shell parser, formatter, and interpreter with BASH support https://github.com/mvdan/sh (Submitted often but not yet discussed) --- /me whispers: Hint: You could be that guy [1] (or gal, they, it, etc): /submit shmfmt Feel free to leave a link to y…
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.
fmt.Errorf with %w is how you do this since Go 1.13, gotta drop that dep