코드를 직접 살펴보겠습니다.
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 언어 유형 비교 기사에서 우리는 다음과 같이 말했습니다. 인터페이스 인터페이스의 경우 비교에는 동적 유형과 동적 값이라는 두 가지 차원이 있습니다. 인터페이스 <code style='font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;background: rgba(14, 210, 247, 0.15);'><span style="font-size: 15px;">==</span>
比较,只有在类型与值均相等的情况下才会为真。
type error interface { Error() string }
<span style="font-size: 15px;">someWork</span>
==비교, 유형이 다음과 같은 경우에만 with 값이 동일한 경우에만 true가 됩니다.
func bar() { var err error err = foo() if err == nil { // 程序正常的代码逻辑 } else { switch err.(type) { case err1: // 做错误处理1 case err2: // 做错误处理2 default: // 做通用错误处理 } } }
<h2 data-tool="mdnice编辑器" style="margin-top: 30px;margin-bottom: 15px;font-weight: bold;font-size: 22px;border-bottom: 4px solid rgb(160, 249, 176);display: flex;">someWork<span style="width: 100%;display: flex;color: rgba(160, 249, 176);padding: 0.5rem 1rem;border-top-left-radius: 4px;border-top-right-radius: 4px;background: #181a21 !important;"></span>
</h2>
함수에서 반환된 오류 유형이 MyselfError이고 값이 nil인 오류 인터페이스는 분명히 요구 사항을 충족하지 않습니다. 유형과 값이 모두 nil인 경우에만 인터페이스 유형에 대한 nil 판단이 true가 됩니다.
🎜메인 브랜치 코드🎜🎜🎜🎜위의 예를 보면 제가 무슨 말을 하려는지 이해가 되시겠죠? 🎜🎜在 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!