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
Gofumpt: A stricter gofmt
51–60 of 93 posts
Re: Gofumpt: A stricter gofmt
#52Good. 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.
Re: Gofumpt: A stricter gofmt
#53Hate 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…
Re: Gofumpt: A stricter gofmt
#54The 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
#55Hate 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…
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
#56No 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…
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
#57Re: Gofumpt: A stricter gofmt
#58Hate 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
#59Earlier 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…
Isn't that a function of font size rather than screen resolution?
Re: Gofumpt: A stricter gofmt
#60Hate 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 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.