筆記：一直很討厭把布林值當參數，因為看不出意圖

主要觀點

• 直接把布林值（Boolean）當作函數參數，容易讓人看不出意圖，例如 deliveryDate(order, true)，外部無法直觀判斷 true 代表什麼。

• 把布林值改成字串參數（如 "rush"）在參數多時也會降低可讀性。

改善方法

• 將流程判斷的布林參數，直接拆成兩個語意明確的函數，例如：

  • rushDeliveryDate(order)

  • regularDeliveryDate(order)

• 如果不是用來判斷流程，傳 string、變數、物件等參數則沒問題。

• 可以用物件參數（具名參數）或加上參數名稱提升可讀性，例如：

  • deliveryDate({ order, isRush: true })

實際程式碼範例

1. 不推薦：直接傳布林值

function deliveryDate(order, isRush) {
  if (isRush) {
    // 加急處理
    return calculateRushDelivery(order);
  } else {
    // 一般處理
    return calculateRegularDelivery(order);
  }
}

// 調用時
const date1 = deliveryDate(order, true);  // 這裡的 true 不直觀
const date2 = deliveryDate(order, false); // 這裡的 false 也不直觀

2. 改善：拆成兩個函數

function rushDeliveryDate(order) {
  return calculateRushDelivery(order);
}

function regularDeliveryDate(order) {
  return calculateRegularDelivery(order);
}

// 調用時
const date1 = rushDeliveryDate(order);      // 一看就知道是加急
const date2 = regularDeliveryDate(order);   // 一看就知道是一般

3. 進階：用物件參數（可讀性更高）

function deliveryDate({ order, isRush }) {
  if (isRush) {
    return calculateRushDelivery(order);
  } else {
    return calculateRegularDelivery(order);
  }
}

// 調用時
const date1 = deliveryDate({ order, isRush: true });
const date2 = deliveryDate({ order, isRush: false });

其他觀點

• 造成意圖不明的根本原因是「沒有參數名稱」，不只是布林值，任何字面常數（string、int等）都可能有同樣問題。

• 有人認為，註解或 IDE 的 inlay hint 也能幫助理解，但本質還是要讓程式碼本身語意清楚。

• 拆成多個函數雖然意圖明確，但實際應用還是要視情境決定。

小結

• 目標是讓程式碼意圖清楚、易於維護。

• 避免傳遞不具語意的布林或常數參數，能提升團隊協作與程式品質。

個人心得

感覺這件事情並沒有到那麼嚴重，vs code hover 過去也看得到參數命名，那到底要不要拆成兩個，多數情況大多數人的確不會，說實在話這到底會不會有點 over design 呢？