這項看似激進的建議，正越來越多地出現在現代 JavaScript 代碼規(guī)范（如 Airbnb 的部分推薦、函數式編程社區(qū)的最佳實踐）中。它并非要徹底消滅 else，而是倡導一種更清晰、更易于維護的編碼范式。

理解這項規(guī)范背后的深層原因，將幫助我們寫出更高質量、更具可讀性的代碼。這不僅僅是一個風格問題，更是一種思維方式的轉變。

一、問題的根源：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 都代表一個分支，分支越多、嵌套越深，代碼就越難理解和維護。

二、核心理念：快速返回

這項規(guī)范建議的核心，是推崇一種被稱為 “衛(wèi)語句（Guard Clauses）” 或 “快速返回（Early Return）” 的設計模式。

這種模式的指導思想是：在函數的開頭，優(yōu)先處理所有的異常、邊緣或無效情況，并立即返回。 這樣，函數的主體部分就可以專注于處理“快樂路徑（Happy Path）”，即最核心、最正常的邏輯。

讓我們用“快速返回”的思路重構上面的例子：

看到了嗎？代碼發(fā)生了質的變化：

• 扁平化結構：嵌套層級大大減少，代碼從一棵“樹”變成了一條“直線”。
• 降低認知負荷：我們可以像讀一個清單一樣閱讀代碼。檢查完一個條件，如果不滿足就結束。我們不需要在腦海中保留“如果…那么…否則…”的上下文。
• 關注點分離：函數的開頭部分是“防御性”的，負責過濾掉無效輸入。函數的主體部分則可以專注于核心業(yè)務邏輯，代碼意圖更加清晰。
• 可維護性增強：當我們需要增加一個新的條件（比如“黑名單用戶”），我們只需在函數的開頭添加一個新的衛(wèi)語句即可，而無需在復雜的 else 嵌套中找到正確的位置。

三、帶來的其他好處

除了降低認知負荷，這種編碼風格還有其他優(yōu)點：

1. 鼓勵使用更具表現力的數據結構

有時，一長串的 if...else if...else 結構，實際上可以用更優(yōu)雅的數據結構來代替，比如 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/else
const isFrontendDev = true;
const message = isFrontendDev ? "歡迎關注 FedJavaScript" : "推薦關注 FedJavaScript";

這并不是說要用三元運算符替代所有 if，但對于簡單的賦值操作，它顯然更簡潔、更具表現力。

四、這不是一條死板的教條

需要強調的是，“禁止使用 else”并不是一條必須無條件遵守的鐵律。它的真正目的是促使我們思考：

• 我的代碼是否存在過深的嵌套？
• 我是否可以應用“快速返回”模式來簡化邏輯？
• 這里是否可以用一個更合適的數據結構或設計模式來代替冗長的條件判斷？

在某些非常簡單的、二元對立的情況下，一個清晰的 if...else 結構可能仍然是最直觀的選擇。

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

在這種情況下，強行移除 else 可能會讓代碼變得更難懂，那就得不償失了。

這項規(guī)范建議，實際上是在引導我們從“能用”的代碼，走向“好用、好讀、好維護”的代碼。它挑戰(zhàn)了我們的編碼習慣，迫使我們采用一種更線性、更扁平化的思維方式。