Hello everyone, I’m fried fish.
When programming development in any language, as long as multiple people are involved in collaboration, it is bound to encounter a big problem that is a long struggle. That is: coding style.
Go, PHP, Java, C++; Elementary, intermediate, advanced, management style; The traditional and the Internet are different.
For example, the classic judgment scenario: if err != nil, can write at least three modes. The following code is as follows:
Which way to use in the team? Looking at performance? See style? See a few fewer spaces? See who has the biggest fist?
It’s a question that is often overt and covert.
One of the proverbs in Go is: “Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite”. Roughly speaking, no one likes the style of Gofmt, but Gofmt is everyone’s favorite.
Why? Love and don’t love.
Let’s start with the functionality of Gofmt, which can format Go programs, use tabs to indent, use spaces to align, and make your code look the same.
No matter who it is, how to write it. As long as the IDE and Gofmt are configured, they will become the following format:
So in Go, the coding style controversy becomes pointless. Controlled by the authorities, if there is a contradiction, it will also be transferred to the Go team itself (shout: transfer the contradiction to the outside).
On the whole, everyone will still be more inclined to move closer to the officially defined style, to meet the standards, which can reduce a lot of disputes.
That’s why “Gofmt is everyone’s favorite”, of course. I think it’s probably better to call it “Team Favorite.”
As the proverb goes, no one likes Gofmt’s style. What does this mean?
Real community friends will encounter such scenes. As shown in the following figure:
In fact, Gofmt has a lot of alignment with some of the small partners do not like it, want to change. It’s a pity… No, Go is all about being completely consistent.
Even as some students mentioned in community issues, the rsc of the Go core team also gave a clear and direct reply:
For the design of Go, it is important that Gofmt is not configured. This is not possible if you want to add configurable normalization.
The proverb says that no one likes Gofmt because it’s a mandatory thing, it’s not about your liking or not, someone always likes a different canonical format.
The standardization of Go programming specifications is unified, and there are good and bad from different perspectives. But when you accept a historically new code that is neatly coded in Gofmt and still consistent with the code format you’ve seen 10 years later, that’s a really good benefit.
From the perspective of the language itself, it is one of the important reasons for Go’s success, so that many teams and many people have reduced a lot of disputes, and the merits are greater than the excesses, and there is a considerable need for existence.
What do you think?
Follow and fry fish WeChat,
Get first-hand industry news and knowledge to pull you into the communication group 👇
Hello, I’m fried fish, published the Go bestseller “Go Language Programming Journey”, and then won the GOP (the most opinionated expert in the Go field) honor, click on the blue word to see my book path.
Share high-quality articles every day, output Go interviews, work experience, architecture design, add WeChat to pull reader communication groups, and communicate with everyone!