編寫可讀代碼的藝術（簡體書）

細節決定成敗，思路清晰、言簡意賅的代碼讓程序員一目了然；而格式凌亂、拖沓冗長的代碼讓程序員一頭霧水。除了可以正確運行以外，優秀的代碼必須具備良好的可讀性，編寫的代碼要使其他人能在最短的時間內理解才行。本書旨在強調代碼對人的友好性和可讀性。
《O’Reilly精品圖書系列：編寫可讀代碼的藝術》關注編碼的細節，總結了很多提高代碼可讀性的小技巧，看似都微不足道，但是對于整個軟件系統的開發而言，它們與宏觀的架構決策、設計思想、指導原則同樣重要。編碼不僅僅只是一種技術，也是一門藝術，編寫可讀性高的代碼尤其如此。如果你要成為一位優秀的程序員，要想開發出高質量的軟件系統，必須從細處著手，做到內外兼修，本書將為你提供有效的指導。
主要內容：
·簡化命名、注釋和格式的方法，使每行代碼都言簡意賅。
·梳理程序中的循環、邏輯和變量來減小復雜度并理清思路。
·在函數級別解決問題，例如重新組織代碼塊，使其一次只做一件事。
·編寫有效的測試代碼，使其全面而簡潔，同時可讀性更高。

Dustin Boswell，畢業于加州理工大學，資深軟件工程師，在Google就職多年，負責Web爬蟲和程序設計相關的工作。他專注于前端、後端，服務器架構、機器學習、大數據、系統和網站等技術領域的研究和實踐，經驗十分豐富。他現在是MyLikes的軟件工程師。
Trevor Foucher，資深軟件工程師和技術經理，先後在Microsoft和Google工作了數十年，在Microsoft擔任軟件工程師、技術經理以及安全產品技術主管，在Google從事廣告應用開發和搜索基礎結構研發相關的工作。

寫出的代碼能讓人快速理解、輕松維護、容易擴展的程序員才是專業的程序員。本書關注編碼的細節，總結了很多提高代碼可讀性的小技巧。如果你要成為一位優秀的程序員，要想開發出高質量的軟件系統，必須從細處著手，做到內外兼修，本書將為你提供有效的指導。

前言
第1章 代碼應當易于理解
是什么讓代碼變得';更好';
可讀性基本定理
總是越小越好嗎
理解代碼所需的時間是否與其他目標有沖突
最難的部分

第一部分 表面層次的改進
第2章 把信息裝到名字里
選擇專業的詞
避免像tmp和retval這樣泛泛的名字
用具體的名字代替抽象的名字
為名字附帶更多信息
名字應該有多長
利用名字的格式來傳遞含義
總結
第3章 不會誤解的名字
例子：Filter()
例子：Clip(text， length)
推薦用first和last來表示包含的范圍
推薦用begin和end來表示包含/排除范圍
給布爾值命名
與使用者的期望相匹配
例子：如何權衡多個備選名字
總結
第4章 審美
為什么審美這么重要
重新安排換行來保持一致和緊湊
用方法來整理不規則的東西
在需要時使用列對齊
選一個有意義的順序，始終一致地使用它
把聲明按塊組織起來
把代碼分成';段落';
個人風格與一致性
總結
第5章 該寫什么樣的注釋
什么不需要注釋
記錄你的思想
站在讀者的角度
最後的思考--克服';作者心理阻滯';
總結
第6章 寫出言簡意賅的注釋
讓注釋保持緊湊
避免使用不明確的代詞
潤色粗糙的句子
精確地描述函數的行為
用輸入/輸出例子來說明特別的情況
聲明代碼的意圖
';具名函數參數';的注釋
采用信息含量高的詞
總結

第二部分 簡化循環和邏輯
第7章 把控制流變得易讀
條件語句中參數的順序
if/else語句塊的順序
條件表達式（又名';三目運算符';）
避免do/while循環
從函數中提前返回
臭名昭著的goto
最小化嵌套
你能理解執行的流程嗎
總結
第8章 拆分超長的表達式
用做解釋的變量
總結變量
使用德摩根定理
濫用短路邏輯
例子：與復雜的邏輯戰斗
拆分巨大的語句
另一個簡化表達式的創意方法
總結
第9章 變量與可讀性
減少變量
縮小變量的作用域
只寫一次的變量更好
最後的例子
總結

第三部分 重新組織代碼
第10章 抽取不相關的子問題
介紹性的例子：findClosestLocation()
純工具代碼
其他多用途代碼
創建大量通用代碼
項目專有的功能
簡化已有接口
按需重塑接口
過猶不及
總結
第11章 一次只做一件事
任務可以很小
從對象中抽取值
更大型的例子
總結
第12章 把想法變成代碼
清楚地描述邏輯
了解函數庫是有幫助的
把這個方法應用于更大的問題
總結
第13章 少寫代碼
別費神實現那個功能--你不會需要它
質疑和拆分你的需求
保持小代碼庫
熟悉你周邊的庫
例子：使用Unix工具而非編寫代碼
總結

第四部分 精選話題
第14章 測試與可讀性
使測試易于閱讀和維護
這段測試什么地方不對
使這個測試更可讀
讓錯誤消息具有可讀性
選擇好的測試輸入
為測試函數命名
那個測試有什么地方不對
對測試較好的開發方式
走得太遠
總結
第15章 設計并改進';分鐘/小時計數器';
問題
定義類接口
嘗試1：一個幼稚的方案
嘗試2：傳送帶設計方案
嘗試3：時間桶設計方案
比較三種方案
總結
附錄 深入閱讀

第1章
代碼應當易于理解
在過去的五年里，我們收集了上百個';壞代碼';的例子（其中很大一部分是我們自己寫的），并且分析是什么原因使它們變壞，使用什么樣的原則和技術可以讓它們變好。我們發現所有的原則都源自同一個主題思想。
關鍵思想
代碼應當易于理解
我們相信這是當你考慮要如何寫代碼時可以使用的最重要的指導原則。貫穿本書，我們會展示如何把這條原則應用于你每天編碼工作的各個不同方面。但在開始之前，我們會詳細地介紹這條原則并證明它為什么這么重要。
是什么讓代碼變得';更好';
大多數程序員（包括兩位作者）依靠直覺和靈感來決定如何編程。我們都知道這樣的代碼：
for (Node* node = list->head; node != NULL; node = node->next)
Print(node->data);
比下面的代碼好：
Node* node = list->head;
if (node == NULL) return;
while (node->next != NULL) {
Print(node->data);
node = node->next;
}
if (node != NULL) Print(node->data);
（盡管兩個例子的行為完全相同。）
但很多時候這個選擇會更艱難。例如，這段代碼：
return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);
它比下面這段要好些還是差些？
if (exponent >= 0) {
return mantissa * (1 << exponent);
} else {
return mantissa / (1 << -exponent);
}
第一個版本更緊湊，但第二個版本更直白。哪個標準更重要呢？一般情況下，在寫代碼時你如何來選擇？
......;