为什么不建议使用goto

前提

最近在公司代码review过程中, 看到同事的代码中大量使用了goto, 我给出了"不用 goto"的建议. 但其给出的理由是使用goto更简单. 确实, 使用goto可以使得逻辑更简单直接, 但前提是不乱用goto, 而在公司的项目中又很难保证这一点.

问题

使用goto带来的最直观的问题就是逻辑的复杂度直线升高. 举个例子来展现goto是如何一步步导致逻辑破败不堪的. (当然, 这个例子是我臆想出来的场景)

首先, 我们有一个创建订单并验证支付的需求:

package mainimport "fmt"func main() {fmt.Println("处理订单开始")fmt.Println("Step 1: 创建订单")fmt.Println("Step 2: 验证订单")fmt.Println("Step 3: 验证付款信息")fmt.Println("Step 4: 订单完成")fmt.Println("处理订单结束")
}

此时逻辑很清楚吧. 现在, 我们要对验证订单的结果进行处理, 如果验证失败, 则进行错误处理, 很合理吧:

package mainimport "fmt"func main() {fmt.Println("处理订单开始")fmt.Println("Step 1: 创建订单")var validErr errorfmt.Println("Step 2: 验证订单")if validErr != nil {goto Fail}fmt.Println("Step 3: 验证付款信息")fmt.Println("Step 4: 订单完成")goto End
Fail:fmt.Println("验证付款失败")
End:fmt.Println("处理订单结束")
}

现在, 新的需求来了:

1. 付款信息处理可能因各种原因失败, 需要重试, 最多重试3次
2. 验证订单也可能失败(异步接口验证, 网络抖动等), 需要重试, 最多重试3次
3. 若订单验证失败, 需要提示并重新创建订单

package mainimport "fmt"func main() {fmt.Println("处理订单开始")CreatOrder:fmt.Println("Step 1: 创建订单")validRetryNum := 0
ValidOrder:var validErr errorfmt.Println("Step 2: 验证订单")if validErr != nil {validRetryNum++if validRetryNum <= 3 {goto ValidOrder}fmt.Println("订单验证失败")goto CreatOrder}checkRetryNum := 0
CheckOrder:var checkErr errorfmt.Println("Step 3: 验证付款信息")if checkErr != nil {checkRetryNum++if checkRetryNum <= 3 {goto CheckOrder}goto CheckErr}fmt.Println("Step 4: 订单完成")goto EndCheckErr:fmt.Println("付款信息验证失败")
End:fmt.Println("处理订单结束")
}

再来:

1. 验证付款信息失败, 可能是因为没有付款等, 需要进行付款处理的逻辑
2. 验证订单付款时, 订单可能认为取消支付, 需要处理资源清理等

package mainimport "fmt"func main() {fmt.Println("处理订单开始")CreatOrder:fmt.Println("Step 1: 创建订单")validRetryNum := 0
ValidOrder:var validErr errorfmt.Println("Step 2: 验证订单")if validErr != nil {validRetryNum++if validRetryNum <= 3 {goto ValidOrder}fmt.Println("订单验证失败")goto CreatOrder}checkRetryNum := 0
CheckOrder:var checkErr errorvar paid, cancel boolfmt.Println("Step 3: 验证付款信息")if checkErr != nil {checkRetryNum++if checkRetryNum <= 3 {goto CheckOrder}goto CheckErr}if cancel {goto CancelOrder}if !paid {goto ProcessOrder}fmt.Println("Step 4: 订单完成")goto EndCheckErr:fmt.Println("付款信息验证失败")goto EndCancelOrder:fmt.Println("取消订单支付")goto EndProcessOrder:fmt.Println("处理付款信息")goto CheckOrderEnd:fmt.Println("处理订单结束")
}

再来

1. 增加处理失败的日志记录
2. 增加订单验证失败的日志记录
3. 不管是取消订单支付, 还是付款处理失败, 都需要进行一些清理工作

package mainimport "fmt"func main() {fmt.Println("处理订单开始")CreatOrder:fmt.Println("Step 1: 创建订单")validRetryNum := 0checkRetryNum := 0var checkErr errorvar validErr errorvar paid, cancel bool
ValidOrder:fmt.Println("Step 2: 验证订单")if validErr != nil {validRetryNum++if validRetryNum <= 3 {goto ValidOrderErrorLog}fmt.Println("订单验证失败")goto CreatOrder}CheckOrder:fmt.Println("Step 3: 验证付款信息")if checkErr != nil {checkRetryNum++if checkRetryNum <= 3 {goto CheckOrderErrorLog}goto CheckErr}if cancel {goto CancelOrder}if !paid {goto ProcessOrder}fmt.Println("Step 4: 订单完成")goto EndValidOrderErrorLog:fmt.Println("记录订单验证失败")goto ValidOrderCheckOrderErrorLog:fmt.Println("记录付款验证失败")goto CheckOrderCheckErr:fmt.Println("付款信息验证失败")goto CleanOrderCancelOrder:fmt.Println("取消订单支付")goto CleanOrderProcessOrder:fmt.Println("处理付款信息")goto CheckOrderCleanOrder:fmt.Println("订单关闭的清理工作")goto EndEnd:fmt.Println("处理订单结束")
}

现在, 如果你还觉得逻辑清晰, 那我只能说一句"牛".

代码演进到现在, 逻辑已经十分混乱了, 逻辑的混乱会导致一系列问题:

1. 难以理解, 逐步增加后续迭代的成本
2. 造成额外的心智负担
3. 追踪困难
4. 如果是if for 在逻辑上是自上而下的, 但引入 goto会导致逻辑上下横跳
5. 等等

可能有人会觉得我举的例子有些极端, 实际中没有人会这么做. 那是因为例子总是简单化的, 现实中的场景实际上要更加复杂:

1. 大段逻辑分散: 例子中的所有单条print语句, 在实际项目中都可能会对应一大段的逻辑
2. 最小改动原则: 对现有项目进行改动的时候(尤其是需求要的比较急, 要求改动最小实现功能), 对现有代码的改动越小, 则风险越小. 因此逻辑会越堆越难以理解, 直至最后无法使用
3. 每个人的水平不同: 同一份代码会由团队中的不同人在不同时间维护, 即使你自信自己的水平, 也无法保证代码在未来不会向着这个方向发展

使用场景

当然, 我也不是把goto一棒子打死, 同事在反驳我的时候也给出了强有力的理由"Go 标准库也存在大量使用goto的地方". 比如:

func ParseMAC(s string) (hw HardwareAddr, err error) {if len(s) < 14 {goto error}if s[2] == ':' || s[2] == '-' {if (len(s)+1)%3 != 0 {goto error}n := (len(s) + 1) / 3if n != 6 && n != 8 && n != 20 {goto error}// ...} else if s[4] == '.' {if (len(s)+1)%5 != 0 {goto error}n := 2 * (len(s) + 1) / 5if n != 6 && n != 8 && n != 20 {goto error}// ...} else {goto error}return hw, nilerror:return nil, &AddrError{Err: "invalid MAC address", Addr: s}
}

这种其实是可以接受的, 能够简化流程, 但是, 但是, 不要忘记我不建议使用goto最重要的一点:

1. 你无法保证自己拥有掌控goto的实力
2. 即使你自信, 也无法保证同事有掌控goto的实力

一旦在使用过程中产生破窗效应, 使用goto破坏的速度一定是比不用要快的多. 代码很快就会脱离掌控.

因此, 为了避免这种情况, 最好的方式就是在最开始杜绝掉.

最后的最后, goto如果能够好好用的话, 确实能够带来一定的便利性, 前提是项目由你一人开发, 或你拥有掌控权可以拒绝某些腐败代码进入代码库.

goto并不可怕, 可怕的是不加限制的乱用goto.

---

欢迎来辩...