Hacker News Reader

Comment by gamache | Hacker News Reader

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.

View on HN

What a lonely hill to die on.

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

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

Someone never had to write a matrix

you mean a single dimension array pretending to be a multi dimensional array? no thanks.

I personally am looking forward to the go tool replaces `go run` etc. for a version that makes additonal whitespace and misalignment into a compiler error!

Not quite the same, but early versions of the gc compiler did run what is now gofmt on your code during compilation.

this but actually earnestly yes

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.

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.

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 is actually about removing a number of chores from programming:

- having to worry about confirming to a style guide

- having to review and/or reformat other peoples code to conform to the style guide

- having to learn the style guide

- having to write a style guide

- having to break flow to format your code properly.

In what way is removing a bunch of gross chores intended to make code readable for others, is this about “toxic processes?”

gofmt and friends remove one of the most toxic processes of all: style guides.

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.

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.

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.

Nah, you still get those diffs when the autoformat rules change

Good thing Go and gofmt are very stable and consider compatibility a significant feature.

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

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.

> This has the added benefit that on a standard 1080 monitor you can see two Python files side by side without horizontal scrolling.

Isn't that a function of font size rather than screen resolution?

You really want to argue that shrinking font from a standard font size will produce legible text like that?

The argument is against super long lines. I think Clean Code suggests something similar to the effect of if you have more than three arguments for a method you are better served taking a class as the argument.

you know that work is supposed to be boring, right?

Reply on news.ycombinator.com