从if else到switch case再到抽象（2）

复杂分支有何坏处

复杂分支有什么坏处？让我从百度 Hi 网页版的老代码里面截取一段出来做个例子。

switch (json.result) {
  case "ok":
    switch (json.command) {
      case "message":
      case "systemmessage":
        if (json.content.from == ""
          && json.content.content == "kicked") {
          /* disconnect */
        } else if (json.command == "systemmessage"
          || json.content.type == "sysmsg") {
          /* render system message */
        } else {
          /* render chat message */
        }
        break;
    }
    break;

这段代码要看懂不难，因此我提一个简单问题，以下这个 JSON 命中哪个分支：

{
  "result": "ok",
  "command": "message",
  "content": {
    "from": "CatChen",
    "content": "Hello!"
  }
}

你很容易就能得到正确答案：这个 JSON 命中 /* render chat message */ （显示聊天消息）这个分支。那么我想了解一下，你是如何作出这个判断的？首先，你要看它是否命中 case “ok”: 分支，结果是命中了；然后，你要看它是否命中 case “message”: 分支，结果也是命中了，所以 case “systemmessage”: 就不用看了；接下来，它不命中 if 里面的条件；并且，它也不命中 else if 里面的条件，所以它命中了 else 这个分支。

看出问题来了吗？为什么你不能看着这个 else 就说出这个 JSON 命中这个分支？因为 else 本身不包含任何条件，它只隐含条件！每一个 else 的条件，都是对它之前的每一个 if 和 else if 进行先非后与运算的结果。也就是说，判断命中这个 else ，相当于判断命中这样一组复杂的条件：

!(json.content.from == "" && json.content.content == "kicked") && !(json.command == "systemmessage" || json.content.type == "sysmsg")

再套上外层的两个 switch case ，这个分支的条件就是这样子的：

json.result == "ok" && (json.command == "message" || json.command == "systemmessage") && !(json.content.from == "" && json.content.content == "kicked") && !(json.command == "systemmessage" || json.content.type == "sysmsg")

这里面有重复逻辑，省略后是这样子的：

json.result == "ok" && json.command == "message" && !(json.content.from == "" && json.content.content == "kicked") && !(json.content.type == "sysmsg")

我们花了多大力气才从简简单单的 else 这四个字母中推导出这样一长串逻辑运算表达式来？况且，不仔细看还真的看不懂这个表达式说的是什么。

这就是复杂分支难以阅读和管理的地方。想象你面对一个 switch case 套一个 if else ，总共有3个 case ，每个 case 里面有3个 else ，这就够你研究的了──每一个分支，条件中都隐含着它所有前置分支以及所有祖先分支的前置分支先非后与的结果。