Live data from Hacker News

Gofumpt: A stricter gofmt

github.com

51–60 of 93 posts

Re: Gofumpt: A stricter gofmt

#51

Earlier quoted context omitted.

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

Nah, you still get those diffs when the autoformat rules change

Good thing Go and gofmt are very stable and consider compatibility a significant feature.

Re: Gofumpt: A stricter gofmt

#52
post #21

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…

There's no accounting for taste to be sure, but I for one won't be patronized by a dumb tool. Formatting is for my team and me to decide, and no one else.

[deleted]

Re: Gofumpt: A stricter gofmt

#53
post #49

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…

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.

Re: Gofumpt: A stricter gofmt

#54
No 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.

Re: Gofumpt: A stricter gofmt

#55
post #49

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…

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.

Re: Gofumpt: A stricter gofmt

#56
post #54

No 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 mo…

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

Re: Gofumpt: A stricter gofmt

#58
post #53
post #49

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…

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

Re: Gofumpt: A stricter gofmt

#59
post #26

Earlier quoted context omitted.

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.

Take PEP8 for example which is Python specific. PEP8 has a rule that code shall not exceed 79 characters. This has the added benefit that on a standard 1080 monitor you can see two Python files side by side without horizontal scrolling. This also has the added benefit of being able to see code diffs without issue. I can see why certain choices are made but only matter if they have sound reasoning and arguments for th…

> This has the added benefit that on a standard 1080 monitor you can see two Python files side by side without horizontal scrolling.

Isn't that a function of font size rather than screen resolution?

Re: Gofumpt: A stricter gofmt

#60
post #49

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…

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

Post reply on HN