易讀程式之美學-提升程式碼可讀性的簡單法則 (The Art of Readable Code)

Dustin Boswell, Trevor Foucher 著、莊弘祥 譯

買這商品的人也買了...

相關主題

商品描述

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

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

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

目錄大綱

前言

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

索引