为什么现代 JavaScript 代码规范开始建议禁止使用 else ?

这项看似激进的建议，正越来越多地出现在现代 JavaScript 代码规范（如 Airbnb 的部分推荐、函数式编程社区的最佳实践）中。它并非要彻底消灭 else，而是倡导一种更清晰、更易于维护的编码范式。

理解这项规范背后的深层原因，将帮助我们写出更高质量、更具可读性的代码。这不仅仅是一个风格问题，更是一种思维方式的转变。

问题的根源：else 带来的认知负荷

if...else 结构本身没有错，但当它被滥用，尤其是嵌套使用时，会显著增加代码的“认知负荷”。这意味着我们的大脑需要花费更多的精力去理解代码的逻辑分支。

来看一个经典的“意大利面条式”代码：

function getDiscount(user) { let discount = 0; if (user.isLoggedIn) { if (user.isVip) { if (user.orderCount > 10) {        discount = 0.2;      } else {        discount = 0.1;      }    } else { if (user.orderCount > 5) {        discount = 0.05;      } else { // No discount for non-VIPs with few orders      }    }  } else { // No discount for guests  } return discount;}

要弄清楚一个普通用户能获得多少折扣，我们需要在大脑中追踪一个复杂的“决策树”。每一个 else 都代表一个分支，分支越多、嵌套越深，代码就越难理解和维护。

核心理念：快速返回

这项规范建议的核心，是推崇一种被称为 “卫语句（Guard Clauses）” 或 “快速返回（Early Return）” 的设计模式。

这种模式的指导思想是：在函数的开头，优先处理所有的异常、边缘或无效情况，并立即返回。 这样，函数的主体部分就可以专注于处理“快乐路径（Happy Path）”，即最核心、最正常的逻辑。

让我们用“快速返回”的思路重构上面的例子：

看到了吗？代码发生了质的变化：

1. 扁平化结构：嵌套层级大大减少，代码从一棵“树”变成了一条“直线”。
2. 降低认知负荷：我们可以像读一个清单一样阅读代码。检查完一个条件，如果不满足就结束。我们不需要在脑海中保留“如果…那么…否则…”的上下文。
3. 关注点分离：函数的开头部分是“防御性”的，负责过滤掉无效输入。函数的主体部分则可以专注于核心业务逻辑，代码意图更加清晰。
4. 可维护性增强：当我们需要增加一个新的条件（比如“黑名单用户”），我们只需在函数的开头添加一个新的卫语句即可，而无需在复杂的 else 嵌套中找到正确的位置。

带来的其他好处

除了降低认知负荷，这种编码风格还有其他优点：

1. 鼓励使用更具表现力的数据结构

有时，一长串的 if...else if...else 结构，实际上可以用更优雅的数据结构来代替，比如 Map 或对象字面量。

else if 链：

function getAnimalSound(animal) { if (animal === 'dog') { return 'woof';  } else if (animal === 'cat') { return 'meow';  } else if (animal === 'bird') { return 'tweet';  } else { return 'unknown';  }}

Map 实现：

这种方式将“数据”和“逻辑”清晰地分离开来，代码更加声明式，易于扩展。

2. 促进函数式编程思维

在函数式编程中，倾向于使用表达式（Expressions）而非语句（Statements）。三元运算符 (?:) 和逻辑运算符 (&&, ||) 都是表达式，它们返回一个值。if...else 是一个语句，它不返回值。

使用三元运算符：

// 代替简单的 if/elseconst isFrontendDev = true;const message = isFrontendDev ? "欢迎关注 FedJavaScript" : "推荐关注 FedJavaScript";

这并不是说要用三元运算符替代所有 if，但对于简单的赋值操作，它显然更简洁、更具表现力。

这不是一条死板的教条

需要强调的是，“禁止使用 else”并不是一条必须无条件遵守的铁律。它的真正目的是促使我们思考：

• 我的代码是否存在过深的嵌套？
• 我是否可以应用“快速返回”模式来简化逻辑？
• 这里是否可以用一个更合适的数据结构或设计模式来代替冗长的条件判断？

在某些非常简单的、二元对立的情况下，一个清晰的 if...else 结构可能仍然是最直观的选择。

if (isSuccess) { handleSuccess();} else { handleError();}

在这种情况下，强行移除 else 可能会让代码变得更难懂，那就得不偿失了。

这项规范建议，实际上是在引导我们从“能用”的代码，走向“好用、好读、好维护”的代码。它挑战了我们的编码习惯，迫使我们采用一种更线性、更扁平化的思维方式。