編寫可讀程式碼的藝術 The Art of Readable Code

📌 30 秒摘要（Layer 3）

一條核心準則：程式碼應該讓別人理解它所需的時間最短。全書都是把這條落實成小技巧——表面層次（命名、排版、註解）、簡化迴圈與邏輯、縮小變數作用域、一次只做一件事、把複雜想法先用自然語言講清楚再寫成程式碼。比《整潔之道》更聚焦「表面可讀性」。

🗺 心智圖（Canvas）

編寫可讀程式碼的藝術

編寫可讀程式碼的藝術

📏 核心定理

🎨 表面層次的改進

🔀 簡化迴圈與邏輯

🧹 重新組織程式碼

🗣 把想法變程式

程式碼的寫法，應讓別人 理解它所需的時間最小化

好名字：具體勝過抽象， 把資訊塞進名字裡

排版：對齊、一致的空行與順序

註解：只寫有價值的， 記錄「為什麼」而非「做什麼」

先處理特例／提早 return， 避免深巢狀

拆解龐大運算式， 用解釋型變數

工具-縮小變數作用域

🎯 什麼情境該想到我

當一個函式/檔案裡變數一堆、你得記住每個在哪被改、心智負擔很重時。

⚙️ 怎麼用

1. 讓變數越晚出現、越早消失：用到才宣告，作用域越小越好。
2. 減少變數數量：刪掉只用一次的中間暫存、消掉沒在用的變數。
3. 偏好不可變（只賦值一次）：越少會變的變數，越好推理。
4. 避免全域/大範圍可變狀態：把狀態關進最小的範圍。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 目標是「同時要記在腦中的變數變少」，不是硬拆到破碎。

🔗 相關工具

• 工具-有意義的命名 —— 互補手段，作用域縮不了時，好名字至少讓人知道它是誰的
• 工具-一次只做一件事 —— 更根本的做法，把任務拆開後變數自然各歸各的範圍

工具-一次只做一件事

🎯 什麼情境該想到我

當一段程式把「取資料 + 轉換 + 驗證 + 輸出」全糊在一起，讀起來很費力時。

⚙️ 怎麼用

1. 列出這段程式做了哪些「任務」（常常一寫就是好幾件）。
2. 讓這些任務依序、分開進行：一個區塊/函式只推進一件任務。
3. 必要時把每件任務提煉成獨立函式（見 工具-提煉函式）。

這條是「函式單一職責」在任何一段程式碼層級的應用，連函式內部都適用。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 「一件事」是相對的抽象層次判斷；能被有意義地再分，就還沒到位。

🔗 相關工具

• 工具-函式短小且單一職責 —— 同一件事的函式層說法，這張講「一段程式碼」，它講「一個函式」的邊界
• 工具-縮小變數作用域 —— 配套手法：把任務拆開後，順手把各段的變數關進各自的範圍，心智負擔才真的降下來
• 工具-提煉函式 —— 拆解的執行工具：辨認出「這段在做另一件事」之後，用它把那段搬出去命名

先用白話把邏輯講一遍， 再照著寫（命名的鏡子）

Link to original

🧰 這本書給我的工具

• 工具-縮小變數作用域 — 變數太多、追蹤困難時
• 工具-一次只做一件事 — 一段程式塞太多任務時

✨ 關鍵重點（Layer 1–2）

• 核心定理：讓「理解程式碼所需的時間」最小化。
• 表面改善：好名字（具體勝過抽象）、對齊排版、只寫有價值的註解。
• 簡化控制流：先處理特例/提早 return、避免深巢狀、拆解龐大運算式。
• 把想法變程式：先用白話把邏輯講一遍，再照著寫（命名的鏡子）。

💬 金句原文（Layer 0）

• 「程式碼的寫法，應該讓別人理解它所需的時間最小化。」

🔗 相關

• 更全面的整潔紀律見 程式碼整潔之道（命名/函式/註解在此互補）