#我們直接看一段程式碼
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 而言,它的比較存在兩個維度,分別是動態類型和動態值。介面的<span style="font-size: 15px;">==</span>
比較,只有在型別與值相等的情況下才會為真。
type error interface { Error() string }
<span style="font-size: 15px;">someWork</span>
函數傳回的err 它是類型為MyselfError,值為nil 的error 接口,顯然不符合要求:只有類型和值同時都為nil 的情況下,介面類型的nil 判斷才會為真。
有了上面的鋪墊,你應該懂我要說什麼了吧?
在 Go 中,不要通过<span style="font-size: 15px;">err == nil</span>
来做逻辑判断条件。这不光是由于使用它会产生潜在的 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: // 做通用错误处理 } } }
现在你能知道测试童鞋为什么喷你吗?
有一个词叫做测试覆盖率,它代表测试用例走过的代码行数。如果你将<span style="font-size: 15px;">err==nil</span>
的判断前置,那这段代码就对于测试不友好。
在测试过程中,有时我们很难人为构造错误的发生,那么很可能测试用例只会走<span style="font-size: 15px;">err==nil</span>
下面的代码逻辑。
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 程式碼的詳細內容。更多資訊請關注PHP中文網其他相關文章!