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

21–30 of 93 posts

Re: Gofumpt: A stricter gofmt

#21

Post by gamache »

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 retire, but when the time comes, I am preparing for this to be the hill I die on.

Re: Gofumpt: A stricter gofmt

#22

Post by rightbyte »

gamache wrote: 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…

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.

Re: Gofumpt: A stricter gofmt

#23

Post by mseepgood »

gamache wrote: 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…

I don't understand your comment. In the first sentences you seem to be in favor of code formatting (me too), pointing out the benefits, then towards the end you seem to be against it.

Re: Gofumpt: A stricter gofmt

#24

Post by oweiler »

watt wrote: post #20

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…

Empty lines let you split your code into assignment/initialization, logic and parameter validation, without requiring you to split everything into tiny functions.

Re: Gofumpt: A stricter gofmt

#25

Post by mvdan »

watt wrote: post #20

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.

Re: Gofumpt: A stricter gofmt

#26

Post by jjgreen »

rightbyte wrote: post #22
gamache wrote: 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…

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.

Re: Gofumpt: A stricter gofmt

#27

Post by olig15 »

watt wrote: post #20

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…

Microsoft have an extension for Visual Studio that does this (and also shrinks lines with {}), I use it every day.

https://marketplace.visualstudio.com/items?itemName=VisualSt... (there’s been a version for the last few versions of Visual Studio too)

Re: Gofumpt: A stricter gofmt

#28

Post by k0k0r0 »

metadat wrote: post #2

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

Re: Gofumpt: A stricter gofmt

#29

Post by tempodox »

gamache wrote: 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.

Re: Gofumpt: A stricter gofmt

#30

Post by 2h »

gamache wrote: 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…

> disallowing the developer from adding any value via formatting

formatting doesn't add value. no one formatting is going to please everyone, so it follows that any formatting is going to piss someone off. So I think the point from the Go team is to remove that distraction and let people focus on whats actually important, the code itself.

Post reply on HN