Nobody likes the Go code style? No, Gofmt is everyone's favorite...

Hello everyone, I am fried fish.

When programming in any language, as long as it involves multi-person collaboration. There is bound to be a big problem in the struggle. That is: coding style.

Go, PHP, Java, C++; primary, intermediate, advanced, management styles; traditional and Internet are different.

who's style is better

For example, in the classic judgment scenario: if err != nil , at least three patterns can be written. The following code:

 # 方式一
if err != nil {
  // do something...
}

# 方式二
if err != nil
{
  // do something...
}

# 方式三
if err != nil { // do something... }

In a team, which one do you choose? See performance? See the style? See how many spaces are needed? Who has the bigger fist?

This is an often open and secret question.

Unified Coding Style

One of the Go proverbs is: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite". Roughly speaking, no one likes Gofmt's style, but Gofmt is everyone's favorite.

Why is this? Love and dislike.

Let's start with the function of Gofmt. It can format Go programs, use tabs to indent, use spaces to align, and make your code the same length.

Whoever writes it. As long as the configuration of IDE and Gofmt is combined, it will become the following format:

 if err != nil {
  // do something...
}

So in Go, coding style disputes become moot. Under the unified control of the official, if there is any conflict, it will be transferred to the Go team itself.

On the whole, everyone will still be more inclined to approach the officially defined style and meet the standards, which can reduce a lot of disputes.

That's why "Gofmt is everyone's favorite", of course. I think it might be more appropriate to call it "team favorite".

no room for expansion

As the saying goes, no one likes Gofmt's style. What does this say?

Real community friends will encounter such scenarios. As shown below:

In fact, Gofmt has many friends who don't like it and want to change it. Sadly... no, Go is all about being completely consistent.

Even some students mentioned it in the community issues, and the rsc of the Go core team also gave a clear and direct reply:

It is very important to the design of Go that Gofmt has no configuration. This is not possible if one wants to add configurable normalization.

The proverb says that no one likes Gofmt, also because it's a mandatory thing, it doesn't matter if you like it or not, there will always be someone who likes a different canonical format.

Summarize

Standard unification of the Go programming specification, good and bad from different perspectives. But when you accept a historical new code, its encoding format is processed by Gofmt neatly, and it is still the same as the code format you see 10 years later, that is indeed a very good benefit.

From the perspective of the language itself, it is one of the important reasons for the success of Go, which has reduced many disputes among many people in many teams. what you think?

The article is continuously updated, you can read it on WeChat by searching [Brain Fried Fish]. This article has been included in GitHub github.com/eddycjy/blog . To learn Go language, you can see the Go learning map and route . Welcome to Star to urge you to update.

Go Book Series

• Introduction to the Go language series: a preliminary exploration of the actual combat of the Go project
• Go Programming Journey: Deep Dive into Go Projects
• Go Language Design Philosophy: Understanding Go Why and Design Thinking
• Go Language Advanced Tour: Go deeper into the Go source code

Recommended reading

• The goto statement turns Go code into spaghetti?
• Go only if err != nil? It's not right to share these elegant handling poses with you!