7 ms·
Gofumpt: A stricter gofmt
- metadat 4y agoSee also: interfacer - Automatically Suggest Interface Types in Go https://github.com/mvdan/interfacer https://github.com/mvdan/interfacer https://news.ycombinator.com/item?id=11397905 https://news.ycombinator.com/item?id=11397905 (9 comments) shmfmt - A shell parser, formatter, and interpreter with BASH support https://github.com/mvdan/sh 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 your submission here for other inquisitive parties to stumble upon. [1] https://youtube.com/watch?v=HQXTxG8JBAw&t=105s https://youtube.com/watch?v=HQXTxG8JBAw&t=105s Transparency: Clip is mildly offensive
- metadat 4y agoAh well, maybe next time :)
- deleted 4y ago[deleted]
- metadat 4y agoLooks like next time is in fact happening now :D Shfmt – format shell programs (like gofmt, rustfmt) https://news.ycombinator.com/item?id=34754116 https://news.ycombinator.com/item?id=34754116 @typical182 - thanks for doing the thing!
- jpe90 4y agooh 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 https://9fans.github.io/plan9port/man/man1/acme.html
- typical182 4y agoI just submitted shfmt separately: https://news.ycombinator.com/item?id=34754116 https://news.ycombinator.com/item?id=34754116 It’s nice, and it probably deserves to be more widely known...
- k0k0r0 4y agoI checked the interfacer and I am a bit sad to that it 1) Is "deprecated" and literally the first sentence states its use is discouraged because often such suggestions are misleading and bad advise. 2) From the readme it appears it just suggest to changes of parameter types in functions to existing interfaces. I was hoping to see something that suggests interface definitions from existing types based on whether share methods with same names. About 2) I guess it is indeed kind of unnecessary as such suggestions are kind of trivial. On the ither hand I recently started to learn how to use interfaces and I have kind of a difficult time to wrap my head around how to make idiomatic use of that concept. So even such trivial help would actually be of some use to me, simply because it removes some cognitive load and I be able to see many examples (even potentially bad, but compiling ones) in front of my eyes.
- akdor1154 4y agoAnyone 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.
- FooBarWidget 4y agoI'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.
- saurik 4y agoIt 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.
- therein 4y agoI enjoy errors.Wrap/Wrapf too.
- oefrha 4y agogithub.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.
- preseinger 4y agofmt.Errorf with %w is how you do this since Go 1.13, gotta drop that dep
- 4y ago
- rickette 4y agogofmt being the official tool avoids bikeshedding over formatting rules. Diverging from the default seems like a step backwards, doesn't it?
- usrme 4y agoIn the roadmap section[1] the author says it's more of an experiment with a possibility that some of the rules might end up in the original 'gofmt' tool. While I agree that Go having a de facto formatter built in is wonderful, there are some absolutely fantastic additions in 'gofumpt' that I do hope wind up in 'gofmt' --- [1]: https://github.com/mvdan/gofumpt#roadmap https://github.com/mvdan/gofumpt#roadmap
- rickette 4y agoOk that sounds great
- burnished 4y agoA little yeah, but I think it still raises the base level of effort to nitpick trivial stuff enough to be effective.
- fivre 4y agovery 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
- deleted 4y ago[deleted]
- 4y ago
- al2o3cr 4y agoGofumpt? Is that Ftumch's cousin? :P
- parhamn 4y agoAm 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.
- mseepgood 4y agoYes, that's how it works.
- alphazard 4y agoIf that's the case, then it's even more "gofmt" than "gofmt". The important thing about "gofmt" is that it's the only canonical way to format an AST, so anything that fights with gofmt would undermine that and never get traction in the Go ecosystem. Operating in the space where gofmt hasn't completely made up it's mind is a great way to experiment with potential improvements.
- watt 4y agoSeems 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.
- oweiler 4y agoEmpty lines let you split your code into assignment/initialization, logic and parameter validation, without requiring you to split everything into tiny functions.
- mvdan 4y agoI 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.
- oefrha 4y agoI 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.
- gamache 4y agoGood. 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 retire, but when the time comes, I am preparing for this to be the hill I die on.
- rightbyte 4y agoYe. 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.
- jjgreen 4y agoThis, 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.
- ricardobeat 4y agoVersion control. Auto-formatting means you'll never, ever, have to deal with diffs where 50% of the changes are indentation, commas and line breaks. There is still room for 'style' in how you write code, what the code does is what matters. Formatting simply removes noise.
- speed_spread 4y agoI agree with this 100%. I would extend it by saying that one you make formatting mandatory, the rules themselves don't matter, as long as they are the same for everyone on the project. One could also make formatting automatic through git hooks and then every one can override their local formatting rules to their liking without breaking the common rules. Eventually you realize that what's really needed is AST-based semantic revision control. Text is a lowest common denominator that all programming tools should go beyond, not just the compilers.
- ayan 4y agogofumpt is great. it should be merged into go proper.
- cyri 4y agousing it for years. much better than gofmt. thanks for all the work!
- KevinMS 4y agoHate 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?
- layer8 4y agoAs 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.
- bxparks 4y agoAs 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 https://go.dev/doc/effective_go#semicolons
- layer8 4y agoI 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.
- nordsieck 4y ago> 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.
- lakomen 4y agoNo ty. I don't like strictness, the strictness of gofmt and the forced layout is enough. Especially I don't like being told to do redundant tasks like commenting obviously named functions. The only thing I'd like to have in gofmt is what goimports does, sorting and dividing imports by local and remote. What I absolutely hate is an enforced 80 char limit. I write on 4k, I can afford much wider, even when viewing on mobile. But whatever, that discussion is pointless anyway. Ty but no ty. Moving on.
- mvdan 4y agoYou might be getting confused. gofmt does not warn about lacking comments, that was golint, which has since been deprecated. gofmt does not divide or re-join imports into groups, but gofumpt does :) Neither gofmt nor gofumpt enforce a character limit on lines. Some form of line length limit is the most common gofumpt feature request by far, but one that I haven't been brave enough to release in any form. Perhaps read gofumpt's README, it has a lot more information.
- davidpfarrell 4y agoFor those who may be interested, my go pre-commit hooks package has built-in support for gofumpt (along with a bunch if other linters): https://github.com/TekWizely/pre-commit-golang https://github.com/TekWizely/pre-commit-golang
- djha-skin 4y agoNotably, this stricter formatter still doesn't take a stance on line length.
- preseinger 4y agoand thank goodness for that
- metadat 4y agoRelated prior discussions: Gofmt No Longer Allows Spaces. Tabs Only - https://news.ycombinator.com/item?id=7914523 https://news.ycombinator.com/item?id=7914523 (2014, 56 comments) Refactoring with go fmt - https://news.ycombinator.com/item?id=6724775 https://news.ycombinator.com/item?id=6724775 (2013, 40 comments) Researchrsc: Gofmt - https://news.ycombinator.com/item?id=996934 https://news.ycombinator.com/item?id=996934 (2009, 34 comments) Tangentially related: Psychological effects of coding style (2016) - https://news.ycombinator.com/item?id=22992914 https://news.ycombinator.com/item?id=22992914 (2020, 71 comments)