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

31–40 of 93 posts

Re: Gofumpt: A stricter gofmt

#31

Post by mvdan »

fivre wrote: post #11
rickette wrote: post #5

gofmt being the official tool avoids bikeshedding over formatting rules. Diverging from the default seems like a step backwards, doesn't it?

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 upstreaming parts of gofumpt. At the end of the day, gofumpt works today - it's just a bit awkward to have it as a third party tool.

That said, it is on my radar to talk to him and make a plan for upstreaming.

Edit: to clarify what I mean with the above: I of course could do the legwork to port my formatting changes to go/printer, the guts of gofmt. The reason I mention Robert is that he'd be the one to consider and approve each formatting change, and review the code changes and tests. That work is trickier than it sounds, because you have to think about the possible effect any formatting change would have on all kinds of existing Go code out there.

Re: Gofumpt: A stricter gofmt

#32

Post by ricardobeat »

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.

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.

Re: Gofumpt: A stricter gofmt

#33

Post by JeremyBanks »

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.

[dead]

Re: Gofumpt: A stricter gofmt

#34

Post by speed_spread »

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.

I agree with this 100%. I would extend it by saying that one you make formatting mandatory, the rules themselves don't matter, as long as they are the same for everyone on the project.

One could also make formatting automatic through git hooks and then every one can override their local formatting rules to their liking without breaking the common rules.

Eventually you realize that what's really needed is AST-based semantic revision control. Text is a lowest common denominator that all programming tools should go beyond, not just the compilers.

Re: Gofumpt: A stricter gofmt

#37

Post by doctor_eval »

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.

Re: Gofumpt: A stricter gofmt

#38

Post by epage »

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.

Re: Gofumpt: A stricter gofmt

#39

Post by ascotan »

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 personally prefer a tool that formats because it avoid me have to go to meetings where I have to discuss coding style (which is even more boring).

Re: Gofumpt: A stricter gofmt

#40

Post by none_to_remain »

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.

Nah, you still get those diffs when the autoformat rules change
Post reply on HN