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 成功的重要原因之一，讓許多團隊許多人減少了很多爭端，功大於過，有相當的存在必要。

你認為呢？

推薦閲讀

• goto 語句讓 Go 代碼變成意大利麪條？

• Go 只會 if err != nil？這是不對的，分享這些優雅的處理姿勢給你！