为什么现代 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）"，即最核心、最正常的逻辑。

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

function getDiscount(user) {
  // 卫语句：处理未登录用户（边缘情况）
  if (!user.isLoggedIn) return 0;
  // 卫语句：处理非VIP且订单少的用户（边缘情况）
  if (!user.isVip && user.orderCount <= 5) return 0;
  // 卫语句：处理非VIP但订单多的用户（次级情况）
  if (!user.isVip && user.orderCount > 5) return 0.05;
  // 卫语句：处理VIP但订单少的用户（次级情况）
  if (user.isVip && user.orderCount <= 10) return 0.1;
  // 快乐路径：处理VIP且订单多的用户（核心情况）
  return 0.2;
}

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

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

带来的其他好处

除了降低认知负荷，"减少 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 实现（更优方案）：

// 数据：存储"动物-叫声"的映射关系
const animalSounds = new Map([
  ['dog', 'woof'],
  ['cat', 'meow'],
  ['bird', 'tweet']
]);

// 逻辑：通过 Map 快速查询，无需条件判断
function getAnimalSound(animal) {
  return animalSounds.get(animal) || 'unknown';
}

这种方式更声明式，新增动物类型时只需修改 Map 数据，无需改动逻辑代码，扩展性更强。

2. 促进函数式编程思维

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

对于简单的赋值操作，用三元运算符替代 if...else 更简洁：

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

这并非要求用三元运算符替代所有 if，而是在合适场景下，用更紧凑的表达式提升代码可读性。

这不是一条死板的教条

需要强调的是，"禁止使用 else" 并非无条件遵守的铁律。它的真正目的是促使我们思考三个问题：

1. 我的代码是否存在过深的嵌套？
2. 我是否可以应用 "快速返回" 模式简化逻辑？
3. 这里是否能用更合适的数据结构替代冗长的条件判断？

在某些 简单的二元对立场景 下，清晰的 if...else 可能是最直观的选择。例如：

javascript

运行

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

这种情况下，强行移除 else（如拆成两个独立 if）反而会让代码变难懂，那就得不偿失了。

总结

"减少 else 使用" 的规范，本质是引导我们从 "能用" 的代码，走向 "好用、好读、好维护" 的代码。它挑战了传统编码习惯，迫使我们采用更线性、更扁平化的思维方式 ------ 最终写出逻辑更清晰、可维护性更强的 JavaScript 代码。