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

61–70 of 93 posts

Re: Gofumpt: A stricter gofmt

#61

Post by mixedCase »

cjpearson wrote: post #50
ricardobeat wrote: post #32

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.

It depends on the formatter you're using. If it's strict about line width you'll end up with a lot of noise in the diffs. Prettier will re-format single-line lists that goes one character over the threshold and then re-condense them once it's able to fit under that threshold. It's not uncommon for a change that adds three classes to three different elements to become a 20 line diff.

Excellent.

Otherwise people sharing that criteria will never fix minor code style issues because "it was that way before, and it's such a minor thing, and it makes my merge harder, please accept the review and ship it don't be unreasonable", and of course we are "reasonable" and end up with thousands of "minor things" over time and the more there are the more people feel it's fine to leave shit in, the less comfortable they feel with the code until eventually they all quit and leave the mess to someone else.

I don't even want to imagine how bad the shitshow is going to get as AI coding assistants gain marketshare.

gofmt's normalization of code formatters was the single greatest achievement Go has to its name, and Prettier was a clear improvement on it. If fixing this crap is bothering anyone's laziness or their artistic sentimentalities then they better get to solving the issue where we're still storing code in source control instead of ASTs and letting the editors render them however the user wants.

Re: Gofumpt: A stricter gofmt

#62

Post by strokirk »

doctor_eval wrote: post #37
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…

What a lonely hill to die on.

Count me in to! There are dozens of us, dozens!

Re: Gofumpt: A stricter gofmt

#63

Post by strokirk »

giancarlostoro wrote: post #47
tempodox wrote: post #29

Earlier quoted context omitted.

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.

Write code as if the next maintainer is a psychotic murderer with your address. Honestly I see gofmt as a lightweight pep8 (from python) and I prefer languages to follow a standard for style and such. I kind of hate when I see people adopt a different style than the rest of the codebase moreso than anything else though. Keep things consistent, I dont want a zoo of inconsistent code styles.

Note that the first rule of pep8 tells us:

> A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important. > However, know when to be inconsistent – sometimes style guide recommendations just aren’t applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best.

Not everyone agrees with this, but just citing pep8 this is one of the more important points to me.

Re: Gofumpt: A stricter gofmt

#64

Post by layer8 »

bxparks wrote: post #58
layer8 wrote: post #53

Earlier quoted context omitted.

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

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

Re: Gofumpt: A stricter gofmt

#65

Post by mixedCase »

mvdan wrote: post #55
KevinMS wrote: 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…

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.

Re: Gofumpt: A stricter gofmt

#66

Post by nordsieck »

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

IMO, vertical space is a precious resource in software development. It shouldn't be squandered without clear and compelling reason.

I'm not saying that there's never a reason for to have extra blank lines. But your example isn't it.

Re: Gofumpt: A stricter gofmt

#67

Post by DangitBobby »

mseepgood wrote: post #23
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.

It was "go deserves this" where "this" is further punishment.

Re: Gofumpt: A stricter gofmt

#68

Post by mvdan »

mixedCase wrote: post #65
mvdan wrote: post #55

Earlier quoted context omitted.

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.

gofumpt will never have formatting knobs, following gofmt's design. But if one of gofumpt's rules forbids a style which is reasonable even if it's not very popular, we might want to make the rule more conservative or remove it entirely.

Re: Gofumpt: A stricter gofmt

#69

Post by preseinger »

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

there is no "visual relationship" between main and a, indentation differentiates blocks, empty lines at block begin/end serve no purpose, please stop doing this

Re: Gofumpt: A stricter gofmt

#70

Post by francislavoie »

epage wrote: post #38
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…

Put another way, writing clean code is like writing prose. You need to clearly break down your thoughtt, whether its sections, paragraphs, sentences, and fragments, or files, functions, blocks, groups of lines. Drove me nuts when working in a C# code base that controlled newlines because I had to break up related thoughts.

Yeah. And when I write comments, I do it in explanation of the chunk of lines below which perform a particular idea. The newline after that chunk is necessary to break up the chunks to give room for another one below, etc.
Post reply on HN