Day 13 談過壞味道、Day 20 談過重構，但這些原則如果只靠「大家自己注意」，在趕時間的時候很容易被犧牲掉。今天要談的是怎麼用工具，把這些規範變成自動化、不需要人工盯著的約束。

一、Linter：靜態分析，抓出潛在問題

定義：Linter（例如 JavaScript 生態系裡的 ESLint）在程式碼「還沒執行」之前，就先分析原始碼，找出潛在的錯誤（例如用了未宣告的變數）以及不符合團隊風格規範的寫法（例如該用 const 卻用了 let）。

二、Formatter：統一排版格式

定義：Formatter（例如 Prettier）專門處理排版相關的風格問題——縮排用幾個空格、要不要加分號、字串要用單引號還是雙引號。它的目的不是抓錯誤，而是讓整個團隊的程式碼，不管是誰寫的，排版風格都保持一致，不再需要在 Code Review 裡為了縮排吵架。

三、Git Hooks：在 commit 前自動把關

定義：Git Hooks 是 Git 在特定操作發生前後，會自動觸發的腳本。搭配 Husky、lint-staged 這類工具，可以設定「每次 commit 之前，自動對這次有改動的檔案跑一次 Linter 和 Formatter」，不符合規範的程式碼甚至可以直接擋下，不讓它被 commit 進版本庫。

四、代購 App 案例

延續 Day 13 的義大利麵程式碼範例：如果當初有設定 pre-commit hook，像 processOrder 那種把商品抓取、訂單計算、資料庫連線、Line 通知全部塞在同一個函式裡的寫法，很可能在 commit 之前就會被 Linter 的「函式過長」規則攔下來，提醒開發者先拆分再送出。

// package.json 裡設定 lint-staged：只對這次有改動的檔案跑檢查，不用每次全專案掃描
{
  "lint-staged": {
    "*.js": ["eslint --fix", "prettier --write"]
  }
}

# .husky/pre-commit —— Git Hook：commit 之前自動執行
npx lint-staged
# 如果 ESLint 偵測到無法自動修正的錯誤，commit 會被擋下，
# 開發者必須先處理完這些問題，才能真的把程式碼送進版本庫

五、結論

Linter 負責抓出程式碼裡「看起來有問題」的地方，Formatter 負責讓排版風格統一，Git Hooks 則是把這兩件事綁進 commit 流程、變成不需要人工提醒的自動化關卡——這三者合起來，才能讓 Day 13、Day 20 談到的那些「程式碼該有的樣子」，不是只停留在原則層面，而是真正被日常的開發流程保護著。