《編寫可讀代碼的藝術》

本書幹貨很多，許多确實可行的建議，是都是寫好代碼的必經之路，下面為我總結的導圖和部分章節的概述。

很好的一本書，推薦給大家。

總結思維導圖

第二章

本章唯一的主題是：把資訊塞入名字中。這句話的含義是，讀者僅通過讀到名字就可以獲得大量資訊。

• 使用專業的單詞————例如，不用Get，而用Fetch或者Download可能會更好，這由上下文決定。
• 避免空泛的名字，像tmp和retval,除非使用它們有特殊的理由。
• 使用具體的名字來更細緻地描述食物————server can start()這個名字就比CanListenOnPort更不清楚
• 給變量名帶上重要的細節————例如，在值為毫秒的變量後面加上_ms,或者在還需要轉義的，為處理的變量前面加上raw_。
• 為作用域大的名字采用更長的名字————不要用讓人費解的一個或兩個字母的名字來命名在幾屏之間都可見的變量。對于隻存在于幾行之間的變量用短一點的名字更好。
• 有目的地使用大小寫、下劃線等————例如，你可以在類成員和局部變量後面加上“_”來區分它們。

第三章

不會誤解的名字是最好的名字————閱讀你代碼的人應該了解你的本意，并不會有其他的了解。遺憾的是，很多英語單詞在用來程式設計時是多義性的，例如filter\length和limit。

在你決定使用一個名字之前，要吹毛求疵一點，來想象一下你的名字會被誤解成什麼。最好的名字是不會誤解的。

當要定義一個ie值的上限或下限時，max_和min_是很好的字首。對于包含的範圍，first和last 是好的選擇。對于包含/排除範圍，begin和end是最好的選擇，因為它們最常用。

當為布爾值命名時，使用is和has這樣的詞來明确表示它是個布爾值，避免使用反義的詞。

要小心使用者對特定詞的期望。例如，使用者會期望get（），或者size（）是輕量的方法。

第四章

大家都願意讀有美感的代碼。通過把代碼用一緻的、有意義的方式“格式化”，可以把代碼變得更容易讀，并且可以讀得更快。

• 如果多個代碼塊做相似的事情，嘗試讓它們有同樣的剪影。
• 把代碼按“列”對齊可以讓代碼更容易浏覽。
• 如果在一段代碼中提到A、B和C，那麼不要在另一段中說B、C和A。選擇一個有意義的順序，并始終用這樣的順序。
• 用空行來把大塊代碼分成邏輯上的“段落”

第五章

注釋的目的是幫助讀者了解作者在寫代碼時已經知道的那些事情。本章介紹了如何發現所有的并不那麼明顯的資訊塊并且把它們寫下來。

什麼地方不需要注釋：

• 能從代碼本身中迅速地推斷的事實
• 用來粉飾爛代碼（例如蹩腳的函數名）的“拐杖式注釋”————應該把代碼改好

你應該記錄下來的想法包括：

• 對于為什麼代碼寫成這樣而不是那樣的内在理由（“指導性批注”）。
• 代碼中的缺陷，使用像TODO：或者XXX：這樣的标記。
• 常量背後的故事，為什麼是這個值。

站在讀者的立場上思考：

• 預料到代碼中哪些部分會讓讀者說：“啊？”并且給它們加上注釋。
• 為普通讀者意料之外的行為加上注釋。
• 在檔案/類的級别上使用“全局觀”注釋來解釋所有的部分是如何一起工作的。
• 用注釋來總結代碼塊，是讀者不緻迷失在細節中。

第六章

本章是關于如何把更多的資訊裝入更小空間裡。下面是一些具體的提示：

• 當像“it”和“this”這樣的代詞可能指代多個事物時，避免使用它們呢。
• 盡量準确地描述函數的行為。
• 在注釋中用精心挑選的輸入/輸出例子進行說明。
• 聲明代碼的高層次意圖，而非明顯的細節。
• 用嵌入的注釋來解釋難以了解的函數參數。
• 用含義豐富的詞來使注釋簡潔

第七章

有幾種方法可以讓代碼的控制流更易讀

    在寫一個比較時（while(bytes_expected>bytes_received)）,把改變的值寫在左邊并且把更穩定的值寫在右邊更好一些（while(bytes_received<bytes_expected)）。

    你也可以重新排列if/else語句中的語句塊。通常來講，先處理正确的/簡單的/有趣的情況。有時這些準則會沖突，但是當不沖突時，這是要遵循的經驗法則。

    某些程式設計結構，像三目運算符、do/while循環，以及goto經常會導緻代碼的可讀性變差。最好不要使用它們，因為總是有更整潔的代替方式。

    嵌套的代碼需要更加集中的精力去了解。每層新的嵌套都需要讀者把更多的上下文“壓入棧”。應該把它們改寫成更加“線性”的代碼來避免嵌套。

    通常來講提早傳回可以減少嵌套并讓代碼整潔。“保護語句”（在函數頂部處理簡單的情況時）尤其有用。

第八章

    很難思考巨大的表達式。本章給出了幾種拆分表達式的方法，以便讀者可以一段一段地消化。

    一個簡單的技術是引入“解釋變量”來代表較長的子表達式。這種方式有三個好處：

• 它把巨大的表達式拆分成小段
• 它通過用簡單的名字描述子表達式來讓代碼文檔化
• 它幫助讀者識别代碼中的主要概念

    另一個技術是用德摩根定理來操作邏輯表達式——這個技術有時可以把布爾表達式用更簡潔的方式重寫（例如if(!(a&&!b))變成if(!a||b))。

    本章給出了一個，把一個複雜的邏輯條件拆分成小的語句的例子。實際上，在本章所有改進過的執行個體代碼中，所有的if語句内都沒有超過兩個值。這是理想情況。可能不是總能做到這樣——有時需要把問題“反向”或者考慮目标的對立面。

    最後，盡管本章是關于拆分獨立的表達式的，同樣，這些技術也常常應用于大的代碼塊。是以，你可以在任何見到複雜邏輯的地方大膽地去拆分它們。

第九章

本章是關于程式中的變量是如何快速累積而變得難以跟蹤的。你可以通過減少變量的數量和讓它們盡量“輕量級”來讓代碼更有可讀性。具體有

• 減少變量，即那些妨礙的變量。我們給出了幾個例子來示範如何通過立刻處理結果來消除“中間結果”變量。
• 減少每個變量的作用域，越小越好。把變量移到一個有最少代碼可以看到它的地方。眼不見，心不煩。
• 隻寫一次的變量更好。那些隻設定一次值的變量（或者const、final、常量）使得代碼更容易了解。

第十章

對于本章一個簡單的總結就是“把一般代碼和項目專有的代碼分開”。其結果是，大部分代碼都是一般代碼。通過建立一大組庫和輔助函數來解決一般問題，剩下的隻是讓你的程式與衆不同的核心部分。

這個技巧有幫助的原因是它使程式員關注小而定義良好的問題，這些問題已經同項目的其他部分脫離。其結果是，對于這些子問題的解決方案傾向于更加完整和正确。你也可以在以後重用它們。

第十一章

本章給出了一個組織代碼的簡單技巧：一次隻做一件事情。

如果你有很難讀的代碼，嘗試把它所做的所有任務列出來。其中一些任務可以很容易地變成單獨的函數（或類）。其他的可以簡單地成為一個函數中的邏輯“段落”。具體如何拆分這些任務沒有它們已經分開這個事實那樣重要。難的是要準确地描述你的程式所做的所有這些小事情。

第十二章

    本章讨論了一個簡單的技巧，用自然語言描述程式然後用這個描述來幫助你寫出更自然的代碼。這個技巧出人意料地簡單，但很強大。看到你在描述中所用的詞和短語還可以幫助你發現哪些子問題可以拆分出來。

    但是這個“用自然語言說事情”的過程不僅可以用于寫代碼。例如，某個大學計算機實驗室的規定聲稱當有學生需要别人幫它調試程式時，他首先要對房間角落的一隻專用的泰迪熊解釋他遇到的問題。令人驚訝的是，僅僅通過大聲把問題描述出來，往往就能幫助這個學生找到解決的辦法。這個技巧叫做“橡皮鴨技術”

    另一個看待這個問題的角度是：如果你不能把問題說明或者用詞語來做設計，估計是缺少了什麼東西或者什麼東西缺少了定義。把一個問題（或想法）變成語言真的可以讓它更具體。

第十三章

冒險、興奮——絕地武士追求的并不是這些——尤達大師

本章是關于寫越少代碼越好的。每行新代碼都需要測試、寫文檔和維護。另外，代碼庫中的代碼越多，它就越“重”，而且在其上開發就越難。

    你可以通過以下方法避免編寫新代碼：

• 從項目中消除不必要的功能，不要過度設計。
• 重新考慮需求，解決版本最簡單的問題，隻要能完成工作就行。
• 經常性地通讀标準庫的整個API，保持對它們的熟悉程度。

第十四章

    在測試代碼中，可讀性仍然很重要。如果測試的可讀性很好，其結果是它們也會變得很容易寫，是以大家會寫更多的測試。并且，如果你把事實代碼設計得容易測試，代碼的整個設計會變得更好。

    以下是如何改進測試的幾個具體要點：

• 每個測試的最高一層應該越簡明越好。最好每個測試的輸入/輸出可以用一行代碼來描述。
• 如果測試失敗了，它所發出的錯誤消息應該能讓你容易跟蹤并修正這個bug
• 使用最簡單的并且能夠完整運用代碼的測試輸入。
• 給測試函數取一個有完整描述性的名字，以使每個測試所測到的東西很明确。不要用Test1（），而用像Test_<FunctionName>-<Situation>這樣的名字。

最重要的是，要使它易于改動和增加新的測試。

關于寫高品質代碼的書

《Code Complete:A Practical Handbook of Software Constructionm,2nd edition》,by Steve McConnell

一本嚴謹的大部頭，是關于軟體建構的所有方面的，包括代碼品質以及其他。

《Refactoring:Improving the Design of Existing Code》,by Martin Fowler et al.

一本關于增量代碼改進哲學的好書，包含很多不同重構方法的具體分類，以及要在盡量不破壞東西的情況下做出這些改動所需的步驟。

《The Practice of Programming》,by Brain kernighan and Rob Pike

讨論了程式設計的很多方面，包含調試、測試、可移植性和性能，有很多代碼示例。

《The Pragmatic Programmer:From Journeyman to Master》,by Andrew Hunt and David Thomas

一系列好的程式設計和工程原則，按短小的讨論來組織。

《Clean Code:A Handbook of Agile Software Craftmanship》,by Robert C.Martin

和本書類似（但是專門為Java），還拓展了其他如錯誤處理和并發等話題。

關于各種程式設計話題的書

 《JavaScript:The Good Parts》,by Douglas Crockford

我們認為這本書的精神與我們的書相似，盡管該書不是直接關于可讀性的。它是關于如何使用JavaScript語言中不容易出錯而且更容易了解的一個清晰子集的。

《Effective Java,2nd edition》,by Joshua Block

一個傑出的書，是關于讓你的Java程式更易讀和更少bug的。盡管它是關于Java的，但其中很多原則對所有的語言都适用。強烈推薦。

《Design Patterns:Elements of Reusable Object-Oriented Software》,by Erich Gamma,Richard Helm,Ralph Johnson,and jon Vlissides

這本書是軟體工程師用來讨論面向對程式設計所用的“模式”這種通用語言的原始出處。作為通用的、有用的模式的一覽，它幫助程式員在第一次自己解決棘手問題時避免經常出現的陷阱。

《Programming Pearls,2nd edition》by Jon Beentley

關于真實軟體問題的一系列文章。每一章都有解決真實世界中問題的真知灼見。

《High Performance Web Sites》,by Steve Souders

盡管這不是一本關于程式設計的書，但這本書也值得注意，因為它描述了幾種不需要寫很多代碼就可優化網站的方法

《Joel on Software:And on Diverse and ...》,by Joel Spolsky

來自與http://www.joelonsoftware.com/的一些優秀文章。Spolsky的作品涉及軟體工程的很多方面，并且對很多相關話題都深有見解。一定要讀一讀“Things You should Never Do,Part I”和"The Joel Test:12 Steps To Better code"

轉載于:https://www.cnblogs.com/R-blog/p/4050196.html