《Clean Code》是國外大牛 羅伯特·馬丁 (Robert C. Martin) 的著作 ，在他的這本書中提出了一個概念：
代碼質量與其整潔度成正比
Clean Code 的前提——細節
宏大建築中最細小的部分，比如關不緊的門、有點兒沒鋪平的地板，甚至是凌亂的桌面，都會將整個大局的魅力毀滅殆盡
這通常也是來評估一個產品的標準。
整潔近乎虔誠（Cleanliness is next to godliness）。一張髒亂的桌子足以奪去一所麗宅的光彩
你當用爲自己第一個孩子命名般的謹慎來給變量命名
以上來自書中的三處引用都想說明一句老生常談的話——細節決定成敗。
給我的反思是，在平日工作中的一些細節是不是被忽略掉了，爲了快一點實現一個功能而草草命名函數名與變量名、複製重複性的代碼……
什麼是 Clean Code？
整潔的代碼只做一件事情
Bjarne以“整潔的代碼只做好一件事”結束論斷。毋庸置疑，軟件設計的許多原則最終都會歸結爲這句警語。有那麼多人發表過類似的言論。糟糕的代碼想做太多事，它意圖混亂、目的含混。整潔的代碼力求集中。每個函數、每個類和每個模塊都全神貫注於一事，完全不受四周細節的干擾和污染。
整潔帶來的設計感，
整潔的代碼總是看起來像是某位特別在意它的人寫的。幾乎沒有改進的餘地。
破窗理論
窗戶破損了的建築讓人覺得似乎無人照管。於是別人也再不關心。他們放任窗戶繼續破損。最終自己也參加破壞活動，在外牆上塗鴉，任垃圾堆積。一扇破損的窗戶開闢了大廈走向傾頹的道路。
生活中，當發現某件事物是被設計過的時候，會有一種直擊心底的趕腳，我想在這種時候設計者應該也會有幸福感吧。
有時槽糕的設計可能導致很多人喪生，以前有些大劇院的門是往內開的，在發生火災或一些緊急情況下人們撤離時蜂擁而至堵死了大門，錯過了最佳的逃離時間。
爲什麼需要 Clean Code
先說說不整潔帶來的後果。
假使你是位醫生，病人請求你在給他做手術前別洗手，因爲那會花太多時間，你會照辦嗎？本該是病人說了算；但醫生卻絕對應該拒絕遵從。爲什麼？因爲醫生比病人更瞭解疾病和感染的風險。醫生如果按病人說的辦，就是一種不專業的態度（更別說是犯罪了）。
同理，程序員遵從不瞭解混亂風險的經理的意願，也是不專業的做法。讀與寫花費時間的比例超過10:1。寫新代碼時，我們一直在讀舊代碼。
混亂只會立刻拖慢你，叫你錯過期限。趕上期限的唯一方法——做得快的唯一方法 ——就是始終儘可能保持代碼整潔。
還是關於命名
選個好名字要花時間，但省下來的時間比花掉的多。注意命名，而且一旦發現有更好的名稱，就換掉舊的。這麼做，讀你代碼的人（包括你自己）都會更開心。
關於註釋
註釋的恰當用法是彌補我們在用代碼表達意圖時遭遇的失敗。
註釋是一種代碼不夠清楚表達的表現，這裏當然不是說讓我們不寫註釋，註釋也得整潔
什麼也比不上放置良好的註釋來得有用。什麼也不會比亂七八糟的註釋更有本事搞亂一個模塊。什麼也不會比陳舊、提供錯誤信息的註釋更有破壞性。
去重構吧
不要讓重構的想法在腦海中飄過了，覺得代碼需要重構的時候得儘快。想到一個更合適的變量與函數的命名馬上去替換掉它，這一定會很值得。
在重構過程中，可以應用有關優秀軟件設計的一切知識。提升內聚性，降低耦合度，切分關注面，模塊化系統性關注面，縮小函數和類的尺寸，選用更好的名稱，如此等等。這也是應用簡單設計後三條規則的地方：消除重複，保證表達力，儘可能減少類和方法的數量。
想其他職業一樣，開發也是一門手藝活，所以我們理所應當尊重我們的手藝。
花一點點時間在每個函數和類上。選用較好的名稱，將大函數切分爲小函數，時時照拂自己創建的東西。用心是最珍貴的資源。
