「這本書讓您體認到程式碼的可讀性對後續維護人員有多麼重要。作者透過各種範例，從不同角度解釋可讀性挑戰的種種細節。」
- Michael Hunger, 軟體開發人員，Neo Technology

身為程式設計師，我們曾經看過許多令人頭痛，醜陋又滿是臭蟲的程式碼，在過去五年間，Dustin Boswell 與 Trevor Foucher 兩位作者分析數百個「不良程式」範例（大多數是自己所撰寫），辨識出不良的原因以及改進方式。結論是？撰寫程式時應該儘量縮短其他人理解程式內容所需的時間 -- 即使他人代表的是程式設計師本人。

本書聚焦於基本原則以及能在日常撰寫程式時應用的實務技巧，透過不同程式語言呈現易於理解的程式範例，每章深入程式撰寫中不同的方面，示範如何能讓程式碼更易於理解。

‧簡化命名方式、註解以及程式格式化（formatting）技巧，適用於每一行程式碼
‧改善程式的迴圈、邏輯以及變數，降低複雜度並減少誤解
‧從函數層級解決問題，例如重新組織程式碼的區塊，一次只處理一項工作
‧撰寫有效的測試程式，完整、精簡同時又具有可讀性

Dustin Boswell 畢業於 CalTech，任職於 Google 五年，負責網頁抓取基礎設施（web crawling infrastructure）以及廣告相關程式。他建立了多個網站，喜歡海量資料與機器學習等領域。

Trevor Foucher 曾任職於微軟十餘年，擔任 Windows 與安全相關產品的工程師、經理以及技術負責人，目前任職於 Google 負責廣告程式與搜尋基礎設施。

前言

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 延伸閱讀

索引