原文地址：https://blog.csdn.net/qq754261595/article/details/104495812
1.2 糟糕的代碼
勒布朗（LeBlanc）法則：稍後等於永不（Later equals never）。
1.3.4 整潔代碼的藝術
“整潔感”:它不僅讓我們看到代碼的優劣，還予我們以借戒規之力化劣爲優的攻略。
“代碼感”：缺乏“代碼感”的程序員，看混亂是混亂，無處着手。有“代碼感”的程序員能從混亂中看出其他的可能與變化。“代碼感”幫助程序員選出最好的方案，並指導程序員制訂修改行動計劃，按圖索驥。
簡言之，編寫整潔代碼的程序員就像是藝術家，他能用一系列變換把一塊白板變作由優雅代碼構成的系統。
1.3.5 什麼是整潔代碼
作者一：《C++程序設計語言》的作者
優雅和高效的代碼：（1）代碼邏輯直截了當，讓缺陷難以隱藏；（2）儘量減少依賴關係，使之便於維護；（3）依據某種分層戰略完善錯誤處理代碼；（4）性能調至最優，省的引誘別人做沒規矩的優化，搞出一堆混亂。
破窗理論：窗戶破損了的建築讓人覺得似乎無人照管。於是別人也再不關心。他們放任窗戶繼續破損。最終自己也參加破壞活動，在外牆上塗鴉，任垃圾堆積。一扇破損的窗戶開闢了大廈走向傾頹的道路。
代碼要集中：整潔的代碼力求集中。每個函數、每個類和每個模塊都全神貫注於一事，完全不受四周細節的干擾和污染。
作者二：《面向對象分析與設計》的作者
代碼應當講述事實，不引人猜測。它只該包含必需之物。
作者三：OTI公司創始人
整潔的代碼應可由作者之外的開發者閱讀和增補。它應當有單元測試和驗收測試。它使用有意義的命名。它只提供一種而非多種做一件事的途徑。它只有儘量少的依賴關係，而且要明確地定義和提供清晰、儘量少的API。代碼應通過其字面表達含義，因爲不同的語言導致並非所有必需信息均可通過代碼自身清晰表達。
易讀的代碼和易修改的代碼之間還是有區別的。
下面是三個要點：
（1）整潔繫於測試之上！要在十年之前，這會讓人大跌眼鏡。但測試驅動開發（Test Driven Development）已在行業中造成了深遠影響，成爲基礎規程之一。Dave說得對。沒有測試的代碼不乾淨。不管它有多優雅，不管有多可讀、多易理解，微乎測試，其不潔亦可知也。
（2）“儘量少”。顯然，他推崇小塊的代碼。實際上，從有軟件起人們就在反覆強調這一點。越小越好。
（3） 代碼應在字面上表達其含義。這一觀點源自Knuth的“字面編程”（literate programming）[6]。結論就是應當用人類可讀的方式來寫代碼。
作者四：《極限編程實踐》與《C#極限編程探險》的作者
簡單代碼要點，依其重要排序：（1）能通過所有測試；（2）沒有重複代碼；（3）體現系統中的全部設計理念；（4）包括儘量少的實體，比如類、方法、函數等。
減少重複代碼，提高表達力，提早構建簡單抽象。這就是我寫整潔代碼的方法。代碼重複：如果同一段代碼反覆出現，就表示某種想法未在代碼中得到良好的體現。有意義的命名是體現表達力的一種方式，我往往會修改好幾次纔會定下名字來（藉助工具修改命名）。這麼多年下來，我發現所有程序都由極爲相似的元素構成，避免隨意實現集合行爲，因爲我真正需要的不過是某種簡單的查找手段。
作者五：極限編程創始人之一
如果每個例程都讓你感到深合己意，那就是整潔代碼。如果代碼讓編程語言看起來像是專爲解決那個問題而存在，就可以稱之爲漂亮的代碼。
你無需花太多力氣。那代碼就是深合你意。它明確、簡單、有力。每個模塊都爲下一個模塊做好準備。每個模塊都告訴你下一個模塊會是怎樣的。整潔的程序好到你根本不會注意到它。
漂亮的代碼讓編程語言像是專爲解決那個問題而存在。
1.5 我們是作者
（本段不是抄自原文）作者指出了一個問題，當我們寫代碼的過程中，會花費相當多的時間查看舊的代碼（原文：讀寫與花費時間爲10：1），要讓讀代碼變得簡單。
1.6 童子軍軍規
美國童子軍軍規：讓營地比你來時更乾淨。