前言

1 程式碼應該易於理解
「更好」的意義？
可讀性基本定理
比較短的程式都比較好嗎？
最短理解所需時間與其他目標是否衝突
困難所在

第一部份 表層改善

2 富含資訊的名稱
選擇詞彙
避免 tmp 與 retval 之類的通用名稱
優先使用具體名稱而非抽象名稱
在名稱中加入額外資訊
名稱該有多長？
利用名稱格式加入更多意義
結語

3 不被誤解的名稱
範例：Filter()
範例：Clip(text, length)
包含邊界的極值優先使用 min 與 max
閉區間優先使用 first 與 last
半開放開區間優先使用 begin 與 end
布林值名稱
符合使用者的預期
範例：評估多個可用名稱
結語

4 美學
美學為何重要？
調整斷行讓程式更加一致與簡潔
使用方法（method）消除混亂
適當使用列對齊
選擇有意義的順序並堅守到底
將宣告組織成區塊
區分程式碼「段落」
個人風格與一致性
結語

5 認識註解
不該註解的部份
記錄自己的想法
為讀者設想
最後 - 避免作者區塊
結語

6 讓註解精確與簡潔
維持註解簡潔
避免模稜兩可的代名詞
修整草率的語句
精確描述函數行為
使用具代表性的輸入／輸出範例
表達程式意圖
「函數參數名稱」的註解
使用訊息密集的詞彙
結語

第二部份 簡化迴圈與邏輯

7 提高控制流程可讀性
條件式中的條件順序
if/else 區塊順序
?: 條件式（也稱為「三元運算子」）
避免 do/while 迴圈
儘早由函數中返回
惡名昭彰的 goto
減少巢狀結構
能否理解執行流程？
結語

8 分解巨大表示式
解釋性變數
摘要變數
利用笛摩根定律
誤用捷徑邏輯
範例：與複雜邏輯搏鬥
分解巨大的敘述
另一個有創意的簡化手法
結語

9 變數與可讀性
消除變數
縮限變數的範圍（scope）
偏好單次寫入的變數
最後的範例
結語

第三部份 重新組織程式碼

10 抽離不相關子問題
說明範例：findClosestLocation()
純工具程式碼
其他通用程式碼
建立大量通用程式碼
專案專屬功能
簡化既有介面
依需求重塑介面
過猶不及
結語

11 一次一項工作
工作可以很小
從物件抽取數值
較大的範例
結語

12 將想法轉化為程式碼
清述描述邏輯
認識函式庫能提供的協助
在較大問題應用本方法
結語

13 撰寫較少程式碼
不開發那些功能 - 不會需要
詢問與分解需求
維持程式碼小而美
熟悉使用的函式庫
範例：用 Unix 工具代替撰寫程式
結語

第四部份 精選主題

14 測試與可讀性
讓測試易讀與維護
這些測試有何問題？
讓測試更易讀
讓錯誤訊息易讀
選擇良好的測試輸入
測試函數的命名
那些測試有何問題？
測試友善的開發
過度應用本原則
結語

15 「分／時計數器」的設計與實作
問題說明
定義類別介面

第一次嚐試：粗略的解決方案
第二次嚐試：輸送帶式設計
第三次嚐試：時間區段（Time-Bucketed）設計
比較三種解決方案
結語

A 延伸閱讀

索引

前言

1 程式碼應該易於理解
「更好」的意義？
可讀性基本定理
比較短的程式都比較好嗎？
最短理解所需時間與其他目標是否衝突
困難所在

第一部份 表層改善

2 富含資訊的名稱
選擇詞彙
避免 tmp 與 retval 之類的通用名稱
優先使用具體名稱而非抽象名稱
在名稱中加入額外資訊
名稱該有多長？
利用名稱格式加入更多意義
結語

3 不被誤解的名稱
範例：Filter()
範例：Clip(text, length)
包含邊界的極值優先使用 min 與 max
閉區間優先使用 first 與 last
...