易讀程式之美學：提升程式碼可讀性的簡單法則

　　本書主題是介紹如何寫出有高度可讀性的程式碼，主要概念是程式碼必需易於理解，更精 確地說，撰寫程式碼時應將他人理解程式碼所需的時間縮到最短。

　　本書使用許多不同程式語言的範例解釋這個概念，包含了 C++、Python、JavaScript 以及 Java；避開了程式語言的進階特性，即使不熟悉這些程式語言的讀者，也能夠輕易理解內 容（畢竟，可讀性概念大多與程式語言本身無關）。

　　本書各章節由程式設計的不同層面說明如何讓程式「更易於理解」，共分為四個部份；

　　表層改善
　　名稱、註解與美學：使用在每一行程式碼的簡單技巧。

　　簡化迴圈與邏輯
　　透過改善程式的迴圈、邏輯與變數，提高可讀性的方法。

　　重新組織程式碼
　　組織大區塊程式以及從函數層面解決問題的高階作法。

　　精選主題
　　將「易於理解」原則應用在測試以及大型資料結構的程式。

作者簡介

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

索引

前言

　　我們曾任職於十分成功的軟體公司，和許多傑出工程師一同工作，但仍然遇到許多需要改 善的程式碼，事實上，我們看過許多醜陋的程式碼，讀者可能也是如此。

　　漂亮的程式碼有啟發性，能快速地讓讀者瞭解情況，使用起來也十分有趣，還能激發程式 設計師改善所寫的程式碼。

　　本書目標是協助讀者改善程式碼，「程式碼」是指讀者從編輯器中看到的每一行程式而非 專案的整體架構，也不是指設計模式（design pattern）。這些雖然十分重要，但在我們的 經驗裡，程式設計師大多數的時間是花費在「基本」工作上：變數命名、迴圈以及各式各 樣函數層級的問題。這些大多需要閱讀與編輯原有的程式碼，希望本書能對讀者日常的程 式設計工作有所助益，願意推薦給團隊其他成員。