“軟體開發的一個重要部分是要意識到你的代碼以後將如何影響查看這些代碼的人。兩位作者高屋建瓴，帶你領略這一挑戰的各個方面，並且使用有指導意義的例子來解釋細節。”――Michael Hunger，軟體開發人員
編輯推薦
寫出的代碼能讓人快速理解、輕鬆維護、容易擴展的程式設計師才是專業的程式設計師。本書關注編碼的細節，總結了很多提高代碼可讀性的小技巧。如果你要成為一位優秀的程式設計師，要想開發出高質量的軟體系統，必須從細處著手，做到內外兼修，本書將為你提供有效的指導。
內容簡介
細節決定成敗，思路清晰、言簡意賅的代碼讓程式設計師一目了然；而格式凌亂、拖沓冗長的代碼讓程式設計師一頭霧水。除了可以正確運行以外，優秀的代碼必須具備良好的可讀性，編寫的代碼要使其他人能在最短的時間內理解才行。本書旨在強調代碼對人的友好性和可讀性。
本書關注編碼的細節，總結了很多提高代碼可讀性的小技巧，看似都微不足道，但是對於整個軟體系統的開發而言，它們與巨觀的架構決策、設計思想、指導原則同樣重要。編碼不僅僅只是一種技術，也是一門藝術，編寫可讀性高的代碼尤其如此。如果你要成為一位優秀的程式設計師，要想開發出高質量的軟體系統，必須從細處著手，做到內外兼修，本書將為你提供有效的指導。
主要內容：
■ 簡化命名、注釋和格式的方法，使每行代碼都言簡意賅。
■ 梳理程式中的循環、邏輯和變數來減小複雜度並理清思路。
■ 在函式級別解決問題，例如重新組織代碼塊，使其一次只做一件事。
■ 編寫有效的測試代碼，使其全面而簡潔，同時可讀性更高。
作者簡介
Dustin Boswell，畢業於加州理工大學，資深軟體工程師，在Google就職多年，負責Web爬蟲和程式設計相關的工作。他專注於前端、後端，伺服器架構、機器學習、大數據、系統和網站等技術領域的研究和實踐，經驗十分豐富。他現在是MyLikes的軟體工程師。
Trevor Foucher，資深軟體工程師和技術經理，先後在Microsoft和Google工作了數十年，在Microsoft擔任軟體工程師、技術經理以及安全產品技術主管，在Google從事廣告套用開發和搜尋基礎結構研發相關的工作。
譯者序
在做IT的公司里，尤其是軟體開發部門，一般不會要求工程師衣著正式。在我工作過的一些環境相對寬鬆的公司里，很多程式設計師的衣著連得體都算不上（搞笑的T恤、短褲、拖鞋或者乾脆不穿鞋）。我想，我本人也在這個行列裡面。雖然我現在改行做軟體開發方面的諮詢工作，但還是改不了這副德性。衣著體面的其中一個積極方面是它體現了對周圍人的尊重，以及對所從事工作的尊重。比如，那些研究市場的人要表現出對客戶的尊重。而大多數程式設計師基本上每天主要的工作就是和其他程式設計師打交道。那么這說明程式設計師之間就不用互相尊重嗎？而且也不用尊重自己的工作嗎？
程式設計師之間的互相尊重體現在他所寫的代碼中。他們對工作的尊重也體現在那裡。
在《Clean Code》一書中Bob大叔認為在代碼閱讀過程中人們說髒話的頻率是衡量代碼質量的唯一標準。這也是同樣的道理。
這樣，代碼最重要的讀者就不再是編譯器、解釋器或者電腦了，而是人。寫出的代碼能讓人快速理解、輕鬆維護、容易擴展的程式設計師才是專業的程式設計師。
當然，為了達到這些目的，僅有編寫程式的禮節是不夠的，還需要很多相關的知識。這些知識既不屬於編程技巧，也不屬於算法設計，並且和單元測試或者測試驅動開發這些話題也相對獨立。這些知識往往只能在公司無人問津的編程規範中才有所提及。這是我所見的僅把代碼可讀性作為主題的一本書，而且這本書寫得很有趣！
既然是“藝術”，難免會有觀點上的多樣性。譯者本身作為程式設計師觀點更加“極端”一些。然而兩位作者見多識廣，輕易不會給出極端的建議，如“函式必須要小於10行”或者“注釋不可以用於解釋代碼在做什麼而只能解釋為什麼這樣做”等語句很少出現在本書中。相反，作者給出目標以及判斷的標準。
翻譯書是件費時費力的事情，好在本書恰好涉及我感興趣的話題。但翻譯本書有一點點自相矛盾的地方，因為書中相當的篇幅是在講如何寫出易讀的英語。當然這裡的“英語”大多數的時候只是指“自然語言”，對於中文同樣適用。但鑒於大多數程式語言都是基於英語的（至少到目前為止），而且要求很多程式設計師用英語來注釋，在這種情況下努力學好英語也是必要的。
感謝機械工業出版社的各位編輯幫助我接觸和完成這本書的翻譯。這本譯作基本上可以說是在高鐵和飛機上完成的（我此時正在新加坡飛往香港的飛機上）。因此家庭的支持是非常重要的。尤其是我的妻子鄭秀雯（是的，新加坡的海關人員也對她的名字感興趣），她是全書的審校者。還有我“上有的老人”和“下有的小孩”，他們給予我幫助和關懷以及不斷前進的動力。
尹哲
前言
我們曾經在非常成功的軟體公司中和出色的工程師一起工作，然而我們所遇到的代碼仍有很大的改進空間。實際上，我們曾見到一些很難看的代碼，你可能也見過。
但是當我們看到寫得很漂亮的代碼時，會很受啟發。好代碼會很明確告訴你它在做什麼。使用它會很有趣，並且會鼓勵你把自己的代碼寫得更好。
本書旨在幫助你把代碼寫得更好。當我們說“代碼”時，指的就是你在編輯器裡面要寫的一行一行的代碼。我們不會討論項目的整體架構，或者所選擇的設計模式。當然那些很重要，但我們的經驗是程式設計師的日常工作的大部分時間都花在一些“基本”的事情上，像是給變數命名、寫循環以及在函式級別解決問題。並且這其中很大的一部分是閱讀和編輯已有的代碼。我們希望本書對你每天的編程工作有很多幫助，並且希望你把本書推薦給你團隊中的每個人。
本書內容安排
這是一本關於如何編寫具有高可讀性代碼的書。本書的關鍵思想是代碼應該寫得容易理解。確切地說，使別人用最短的時間理解你的代碼。
本書解釋了這種思想，並且用不同語言的大量例子來講解，包括C++、Python、JavaScript和Java。我們避免使用某種高級的語言特性，所以即使你不是對所有的語言都了解，也能很容易看懂。（以我們的經驗，反正可讀性的大部分概念都是和語言不相關的。）
每一章都會深入編程的某個方面來討論如何使代碼更容易理解。本書分成四部分：
■ 表面層次上的改進：命名、注釋以及審美――可以用於代碼庫每一行的小提示。
■ 簡化循環和邏輯：在程式中定義循環、邏輯和變數，從而使得代碼更容易理解。
■ 重新組織你的代碼：在更高層次上組織大的代碼塊以及在功能層次上解決問題的方法。
■ 精選話題：把"易於理解"的思想套用於測試以及大數據結構代碼的例子。
如何閱讀本書
我們希望本書讀起來愉快而又輕鬆。我們希望大部分讀者在一兩周之內讀完全書。
章節是按照"難度"來排序的：基本的話題在前面，更高級的話題在後面。然而，每章都是獨立的。因此如果你想跳著讀也可以。
目錄
前言 1
第1章 代碼應當易於理解 5
是什麼讓代碼變得“更好” 6
可讀性基本定理 7
總是越小越好嗎 7
理解代碼所需的時間是否與其他目標有衝突 8
最難的部分 8
第一部分 表面層次的改進 9
第2章 把信息裝到名字里 11
選擇專業的詞 12
避免像tmp和retval這樣泛泛的名字 14
用具體的名字代替抽象的名字 17
為名字附帶更多信息 19
名字應該有多長 22
利用名字的格式來傳遞含義 24
總結 25
第3章 不會誤解的名字 27
例子：Filter() 28
例子：Clip(text, length) 28
推薦用first和last來表示包含的範圍 29
推薦用begin和end來表示包含/排除範圍 30
給布爾值命名 30
與使用者的期望相匹配 31
例子：如何權衡多個備選名字 33
總結 34
第4章 審美 36
為什麼審美這么重要 37
重新安排換行來保持一致和緊湊 38
用方法來整理不規則的東西 40
在需要時使用列對齊 41
選一個有意義的順序，始終一致地使用它 42
把聲明按塊組織起來 43
把代碼分成“段落” 44
個人風格與一致性 45
總結 46
第5章 該寫什麼樣的注釋 47
什麼不需要注釋 49
記錄你的思想 52
站在讀者的角度 54
最後的思考――克服“作者心理阻滯” 58
總結 59
第6章 寫出言簡意賅的注釋 60
讓注釋保持緊湊 61
避免使用不明確的代詞 61
潤色粗糙的句子 62
精確地描述函式的行為 62
用輸入/輸出例子來說明特別的情況 63
聲明代碼的意圖 64
“具名函式參數”的注釋 64
採用信息含量高的詞 65
總結 66
第二部分 簡化循環和邏輯 67
第7章 把控制流變得易讀 69
條件語句中參數的順序 70
if/else語句塊的順序 71
?:條件表達式（又名“三目運算符”） 73
避免do/while循環 74
從函式中提前返回 76
臭名昭著的goto 76
最小化嵌套 77
你能理解執行的流程嗎 80
總結 81
第8章 拆分超長的表達式 82
用做解釋的變數 83
總結變數 83
使用德摩根定理 84
濫用短路邏輯 84
例子：與複雜的邏輯戰鬥 85
拆分巨大的語句 87
另一個簡化表達式的創意方法 88
總結 89
第9章 變數與可讀性 91
減少變數 92
縮小變數的作用域 94
只寫一次的變數更好 100
最後的例子 101
總結 103
第三部分 重新組織代碼 105
第10章 抽取不相關的子問題 107
介紹性的例子：findClosestLocation() 108
純工具代碼 109
其他多用途代碼 110
創建大量通用代碼 112
項目專有的功能 112
簡化已有接口 113
按需重塑接口 114
過猶不及 115
總結 116
第11章 一次只做一件事 117
任務可以很小 119
從對象中抽取值 120
更大型的例子 124
總結 126
第12章 把想法變成代碼 127
清楚地描述邏輯 128
了解函式館是有幫助的 129
把這個方法套用於更大的問題 130
總結 133
第13章 少寫代碼 135
別費神實現那個功能――你不會需要它 136
質疑和拆分你的需求 136
保持小代碼庫 138
熟悉你周邊的庫 139
例子：使用Unix工具而非編寫代碼 140
總結 141
第四部分 精選話題 143
第14章 測試與可讀性 145
使測試易於閱讀和維護 146
這段測試什麼地方不對 146
使這個測試更可讀 147
讓錯誤訊息具有可讀性 150
選擇好的測試輸入 152
為測試函式命名 154
那個測試有什麼地方不對 155
對測試較好的開發方式 156
走得太遠 158
總結 158
第15章 設計並改進“分鐘/小時計數器” 160
問題 161
定義類接口 161
嘗試1：一個幼稚的方案 164
嘗試2：傳送帶設計方案 166
嘗試3：時間桶設計方案 169
比較三種方案 173
總結 174
附錄 深入閱讀 175
