第一部分 表面層次的改進
可讀性代碼的改進從 表面層次 的改進開始：選擇好的名字、寫好的注釋、代碼整潔的寫成更好的格式。
第二章——把信息裝到名字里
無論是命名變量、函數還是類，都有很多相同的原則，嘗試把名字當成一個小小的注釋語句，選擇一個好的名字，讓其承載更多的信息。
-
選擇專業的詞
假設你有個Thread類：
class Thread{ void Stop(); };Stop其實還可以，但是如果該線程不能恢復，使用Kill應該更好一些
-
找更有表現力的詞
下面列出一些表現力更強的單詞，依語境采用：
send -> deliver 、 dispatch 、 announce 、 distribute 、 route find -> search 、 extract 、 locate 、 recover start -> lanch 、 create 、 begin 、 open make -> create 、 set up 、 build 、 generate 、 compose 、 add 、 new -
用具體的名字代替抽象的名字
在給變量，函數或者其他元素命名時，要把它描述的更具體而不是更抽象。
-
為名字附帶更多信息
一個變量名就像是一個小小的注釋，有時候我們可以讓它更有幫助些
附帶其他的重要屬性
-
名字應該有多長
- 在小的作用域里可以使用短的名字
- 首字母縮略詞和縮寫: doc = document
- 丟掉沒用的詞
- 利用名字的格式來傳遞含義
第三章——不會誤解的名字
- 推薦使用 min 和 max 來表示（包含）極限
- 推薦使用 first 和 last 來表示包含的范圍
- 推薦使用 begin 和 end 來表示包含/排除范圍
第四章——審美
- 原則：
- 使用一致的布局，讓讀者很快就習慣這種風格
- 讓相似的代碼看上去相似
- 把相關的代碼行分組，形成代碼塊
第五章——該寫怎樣的注釋
- 什么地方不需要這注釋
- 應該記錄下來一些想法：為什么代碼寫成這樣而不是那樣、TODO、常量為什么是這個值
- 站在讀者的角度去思考：
- 預料到那部分的代碼會讓人搞不清楚，加上注釋
- 為讀者意料之外的行加上注釋
- 在文件/類的級別使用“全局觀”注釋來解釋所有的部分如何一起工作的
第六章——寫出言簡意賅的注釋
- 避免使用不明確的代詞
- 盡量精確描述函數的行為
- 精心挑選輸入/輸出的例子
- 聲明代碼的高層次意圖，而非明顯的細節
- 用嵌入注釋解釋難以理解的函數參數
- 用含義豐富的詞語
第二部分——簡化循環和邏輯
第七章——把控制流變得易讀
- 條件語句中參數的順序：左側的值傾向于不斷變化、右側的值更傾向于常量
- if/else 語句塊的順序：首先處理正邏輯而不是負邏輯、先處理簡單的情況
- ?: 表達式：只有在簡單的情況下使用
- 避免 do/while 循環
- 最小化嵌套
- 從函數中提前返回
第八章——拆分超長表達式
-
if line.split(':')[0].strip() == "root"改為username = line.split(':')[0].strip();if username == "root" - 拆分巨大的語句
第九章——變量與可讀性
變量越多，就越難全部跟蹤他們的動向
變量的作用越到，就需要跟蹤它的動向越久
變量改變的越頻繁，就越難以跟蹤它的當前值
- 減少變量，即那些妨礙的變量。通過離開處理結果來消除“中間結果”變量。
- 減少每個變量的作用域，越小越好。
- 只寫一次的變量更好，那些只設置一次值的變量（或者 const 、final 、常量）使得代碼更容易理解。
第三部分——重新組織代碼
第十章——抽取不相關的子問題
第十一章——一次只做一件事
應該把代碼組織得一次只做一件事情。
第十二章——把想法變成代碼
學會用自然語言描述你要實現的功能，寫出和描述匹配的代碼。
第十三章——少寫代碼
- 從項目中消除不必要的功能，不要過度設計
- 重新考慮需求，解決版本最簡單的問題
- 經常性地通讀標準庫的整個API，保持對它們的熟悉程度
第四部分——精選話題
第十四章——測試與可讀性
- 使測試易于閱讀和維護
- 讓錯誤消息更具可讀性
- 選擇好的測試輸入
- 簡化輸入值
- 為測試函數命名
