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

41–50 of 93 posts

Re: Gofumpt: A stricter gofmt

#41

Post by deadbunny »

2h wrote: post #30
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.

Exactly. I prefer writing with double quotes as they are easier to hit for me. When/if the formatter changes them to single quotes I couldn't care less. I can accidentally miss-indent something and the formatter will catch it and fix it. Why spend mental energy making sure I'm perfectly writing trivial things when I can focus on the important stuff?

Re: Gofumpt: A stricter gofmt

#42

Post by typical182 »

mvdan wrote: post #31
fivre wrote: post #11

Earlier quoted context omitted.

very 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…

It's not quite as simple as that :) I think upstreaming half of gofumpt's additions to gofmt would be reasonable, but the person who wrote and maintains gofmt is Robert Griesemer, who continues to be quite busy with generics. They are still actively fixing typechecking bugs and performance issues, as far as I can see. I think it's hard for anyone to justify pausing or distracting the generics work in favor of upstrea…

For open source projects in general, and the Go project in particular, I think it is easy to underestimate how much maintainer time is consumed discussing & considering whether a change should be made.

Re: Gofumpt: A stricter gofmt

#43

Post by 3836293648 »

2h wrote: post #30
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.

Someone never had to write a matrix

Re: Gofumpt: A stricter gofmt

#44

Post by devnullbrain »

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.

The way you've described it is almost verbatim with how Google's C++ style guide puts it:

https://google.github.io/styleguide/cppguide.html#Vertical_W...

Re: Gofumpt: A stricter gofmt

#45

Post by jerf »

jjgreen wrote: post #26
rightbyte wrote: post #22

Earlier quoted context omitted.

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.

"I really don't get why people want to enforce uniformity"

This is engineering, not food choice or movie accents. I don't want your second style in my code for the same reason that if my physical project uses metric tooling, I don't want the intern to come screaming in with imperial tooling, and then get huffy when I complain and ask them to recast their work in metric. Yes, it's true, there's absolutely nothing your imperial tooling can't do... but I still don't want it in my engineering for no benefit.

Engineering innovation is not harmed by being pushed above the basic level of which kind of tooling it uses.

I wonder how many people complaining are actually routine Go programmers. These rules are pretty sensible and clearly written by an experienced Go programmer. To the extent that my code would be modified by this tool, it isn't much. Many of the rules are just unsightly in Go code in practice and many of them I've already wondered why gofmt doesn't already have. For instance, the rule around newlines and brackets; I've often accidentally had a function end with a newline, but it never looks good, it's never something I'm like yes, let me fight for this and I've manually removed it as soon as I've seen it. If someone on my team really went to bat against these rules (and note the "really went to bat", I'm not talking quibbles here & there, we've all got those) I'd have questions about their ability to do basic cost/benefit analysis in such a process.

And, if it isn't engineering, then by all means go nuts with whatever you like. But I think your question only has meaning in a group context, because if you're not in a group context, who cares in the slightest what the non-existent group thinks? I've got plenty of personal projects that I in my own engineering role wouldn't consider to pass even basic engineering muster. You should see my electrical "engineering" work; I would feel dirty if I didn't scare quote the term "engineering". I'm not very good. Tends to look more like a hollywood bomb than anything you see linked in the sort of YouTube video that shows up on HN every so often.

Re: Gofumpt: A stricter gofmt

#46

Post by alphazard »

parhamn wrote: post #18

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

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

Re: Gofumpt: A stricter gofmt

#47

Post by giancarlostoro »

tempodox wrote: post #29
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.

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.

Re: Gofumpt: A stricter gofmt

#48

Post by giancarlostoro »

jjgreen wrote: post #26
rightbyte wrote: post #22

Earlier quoted context omitted.

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.

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

Re: Gofumpt: A stricter gofmt

#49

Post by KevinMS »

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("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?

Re: Gofumpt: A stricter gofmt

#50

Post by cjpearson »

ricardobeat wrote: post #32
jjgreen wrote: 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.

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.
Post reply on HN