Go 代码风格没人喜欢？不对，Gofmt 是所有人的最爱...

大家好，我是煎鱼。

在任何语言进行编程开发时，只要涉及到多人协作。就一定会遇到一个旷世斗争的大问题。那就是：编码风格。

Go 的，PHP 的，Java 的，C++ 的；初级、中级、高级、管理的风格；传统的、互联网的又都不一样。

谁的风格更好

例如经典的判断场景：if err != nil ，至少可以写出三种模式。如下代码：

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

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

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

在团队中，到底选用哪一种方式呢？看性能？看风格？看少打几个空格？看谁拳头大？

这是个经常明的暗里撕逼的问题。

在 Go 的谚语中有一句是：“Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite”。大致的意思是 Gofmt 的风格没有人喜欢，但 Gofmt 是每个人的最爱。

这是为什么呢？又爱又不爱的。

我们先从 Gofmt 的功能来讲，它能够格式化 Go 程序，使用制表符来缩进，使用空格来对齐，能够让你的代码长的都一样。

无论是谁，怎么写。只要结合 IDE 和 Gofmt 一配置，都会变成如下格式：

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

因此在 Go 中，编码风格的争议变得毫无意义。由官方统一管控，若有矛盾也会转移到 Go 团队本身。

综合来看，大家还是会更倾向于往官方定义的风格去靠近，去符合标准，能够减少非常多的争端。

这就是为什么 ”Gofmt 是每个人的最爱“ 的原因了，当然。我认为叫 ”团队的最爱“ 可能更加的适合。

谚语里也提到了，Gofmt 的风格没有人喜欢。这又怎么说？

真实的社区朋友会遇到这类场景。如下图：

实际上 Gofmt 有不少对齐有的小伙伴并不喜欢，想改。很可惜...并不能，Go 就是要完全保持一致。

甚至有同学在社区 issues 提过，Go 核心团队的 rsc 也给出了明确的直接回复：

对于 Go 的设计来讲，Gofmt 没有配置是非常重要的。如果想要增加可配置的规范化，这是不可能的。

谚语说到 Gofmt 没有人喜欢，也是因为它是一个强制性的东西，不关乎你的喜好与否，总有人喜欢不一样的规范格式。

Go 编程规范的标准统一化，从不同的角度来看有好有坏。但当你接受一个历史新代码，它的编码格式都被 Gofmt 处理的整整齐齐，和你 10 年后看到的代码格式依然一致，那也确实是一个很不错的益处。

语言本身来看，它是让 Go 成功的重要原因之一，让许多团队许多人减少了很多争端，功大于过，有相当的存在必要。你认为呢？

文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。