本文轉載自微信公眾號「Golang技術分享」，作者機器鈴砍菜刀。轉載本文請聯系Golang技術分享公眾號。

在公司進行代碼開發，一般都會制定一套編程規范。良好的代碼規范可以改善項目可讀性，提高團隊開發的合作效率。具體在 Go 語言中，我們可以借鑒 Go 官方的 Go Code Review Comments、Uber 開源的 uber-go/guide 項目，大家感興趣可以去學習。

本文我們聚焦于一個點：Go 的 error 判斷。

啟示代碼

我們直接看一段代碼

type MyselfError struct{} 
 
func (m *MyselfError) Error() string { 
 return "實現 error 接口的 Error 方法" 
} 
 
func someWork() *MyselfError { 
 return nil 
} 
 
func main() { 
 var err error 
 err = someWork() 
 fmt.Println(err == nil) 
} 
 
// output: false 

這個例子的輸出可能會讓你感到意外?

這是由于在 Go 中，兩個 nil 的比較也許并不相等。在Go 語言類型可比性一文中我們說過：對于接口 interface 而言，它的比較存在兩個維度，分別是動態類型和動態值。接口的==比較，只有在類型與值均相等的情況下才會為真。

type error interface { 
    Error() string 
} 

someWork函數返回的 err 它是類型為 MyselfError，值為 nil 的 error 接口，顯然不滿足要求：只有類型和值同時都為 nil 的情況下，接口類型的 nil 判斷才會為真。

主分支代碼

有了上面的鋪墊，你應該懂我要說什么了吧?

在 Go 中，不要通過err == nil來做邏輯判斷條件。這不光是由于使用它會產生潛在的 bug，這樣的代碼交于測試童鞋，他們可能也會噴你，你知道是為什么嗎?

我們可以把代碼分為主干代碼和分支代碼，主干代碼代表正常邏輯，分支代碼記錄異常case。兩者最簡單的區分方法就是：在一個函數中，主干代碼與最左側只隔一個 tab 距離，超過一個 tab 距離的為分支代碼。

在處理錯誤返回的函數中，我們應該先做錯誤異常的處理，錯誤處理的邏輯屬于分支代碼，而正常邏輯則應在主干代碼上。

錯誤示例

func bar() { 
 var err error 
 err = foo() 
 if err == nil { 
  // 程序正常的代碼邏輯 
 } else { 
  switch err.(type) { 
  case err1: 
   // 做錯誤處理1 
  case err2: 
   // 做錯誤處理2 
  default: 
   // 做通用錯誤處理 
  } 
 } 
} 

現在你能知道測試童鞋為什么噴你嗎?

有一個詞叫做測試覆蓋率，它代表測試用例走過的代碼行數。如果你將err==nil的判斷前置，那這段代碼就對于測試不友好。

在測試過程中，有時我們很難人為構造錯誤的發生，那么很可能測試用例只會走err==nil下面的代碼邏輯。

規范示例

func main() { 
 var err error 
 err = foo() 
 if err != nil { 
  switch err.(type) { 
  case err1: 
   // 做錯誤處理1 
  case err2: 
   // 做錯誤處理2 
  default: 
   // 做通用錯誤處理 
  } 
 } 
 // 程序正常的代碼邏輯 
} 

這樣的代碼規范，讓我們在初次接手新項目，或者 code review 其他人的代碼時，能夠通過閱讀主干代碼而快速理解地代碼業務邏輯，而不至于陷入瑣碎的 case 處理中。

總結

今天的文章雖然很短，但是希望能給大家帶來啟示。

在 Go 中 err == nil 不需要判斷，而該判斷異常 case，正常邏輯置于主干，異常代碼置于分支。

在開發組內建立起一套良好的代碼規范，會有助于提升代碼可讀性以及工作協作效率。如果你們還沒有類似的規范，那就去參考 Go Code Review Comments、 uber-go/guide 來整活一套?

參考

Go Code Review Comments：https://github.com/golang/go/wiki/CodeReviewComments

uber-go/guide：https://github.com/uber-go/guide