项目中应该禁用fallthrough

fallthrough的用途

在其他语法（非Go，C，PHP）中，switch 有一个特定的现象，就是向下穿越，指的是一旦一个分支 case 满足，则后续分支代码都会被执行。而Go语言中，默认分支执行完毕，switch 执行完毕。使用 fallthrough 语法，可以达到穿越下一个 case 分支的目的。 fallthrough 需要出现在分支语句块的最后一句！ 语法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

switch 分支测试表达式 {
case 状态1:
    分支1
    fallthrough
case 状态2:
    分支2
    fallthrough
default:
    分支 default
}

fallthrough的坑

使用fallthrough的时候，必须注意的一点是，fallthrough会忽略下一分支的状态值，直接执行下一分支。使用fallthrough语句时，必须确保当前分支的条件必然满足下一分支的条件。比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

func check(i uint32) {
    switch {
    case i >= 100:
        fmt.Printf("i(%d) >= 100\r\n",i)
        fallthrough
    case i >= 10:
        fmt.Printf("i(%d) >= 10\r\n",i)
        fallthrough
    default:
        fmt.Printf("i(%d) >= 0\r\n",i)
    }
}

check(100)执行结果如下：

i(100) >= 100
i(100) >= 10
i(100) >= 0

但如果有人错误的修改了分支1的条件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

func check(i uint32) {
    switch {
    case i >= 5:
        fmt.Printf("i(%d) >= 5\r\n",i)
        fallthrough
    case i >= 10:
        fmt.Printf("i(%d) >= 10\r\n",i)
    default:
        fmt.Printf("i(%d) error\r\n",i)
    }
}

check(5)执行结果就崩掉了：

i(5) >= 5
i(5) >= 10
i(5) >= 0

fallthrough是否必选项

• fallthrough可被替代

  个人认为fallthrough并非不可替代，项目中使用到fallthrough的情况无非两种，第一种，两个分支条件不一样，但逻辑一样：

  

  这种情况进行如下修改即可：

  

  另一种，多个分支希望都能被执行到，比如之前check方法，可做如下修改：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  func check(i uint32) { check_5(i) check_10(i) check_0(i) } func check_5(i uint32) { if i >= 5 { fmt.Printf("i(%d) >= 5\r\n",i) } } func check_10(i uint32) { if i >= 10 { fmt.Printf("i(%d) >= 10\r\n",i) } } func check_0(i uint32) { if i >= 0 { fmt.Printf("i(%d) >= 0\r\n",i) } }

  如此设计，不管条件怎么变，检查顺序怎么变，都不会影响执行结果。

• fallthrough容易犯错

  一旦用了fallthrough，这套逻辑的判断条件和顺序都很重要，如果一个新人或者对这段逻辑理解不深的同学来修改代码，一定会出错。我们项目中存在如此代码，就等于把这套检查逻辑的严谨性交给了策划，如果策划配错表了，这套逻辑也就崩溃了。

  

  对于多人协作的项目，而且存在代码能力参差不齐的情况下，使用fallthrough等于给项目埋下了炸弹。

代码规范（条件判断）

• 超过2个else if的情况，应该用switch；
• switch中禁止使用fallthrough；