過年回來開始新的學習生活~也許很長時間沒有感受過太長的假期，或者一直處于緊張的學習生活中，猛然松掉這支皮筋，卻不知道做些什么好，在家的時候就是看電影看電視刷微博，到最后是特別不踏實的感覺，覺得這段時間就像是躺在煙灰缸里的煙屁股，沒有很多的意義。這不是我喜歡的生活，還是更愛忙碌吧~

回來以后看了一本《代碼整潔之道》 的書，作者是Robert C.Martin

這一篇作為讀書筆記，對知識進行梳理和總結

下邊的思維導圖是前7章的內容

第一章 命名

（1）名副其實：變量、函數或類的名稱應該答復了所有的大問題。如果名稱需要注釋來補充，就不算名副其實

（2）避免誤導：程序員必須避免留下掩藏代碼本意的錯誤線索。例如：accountList,List對程序員有特殊意義。除非他是List類型，要不然就會引起錯誤判斷；提防使用不同之處較小的名稱。區分模塊中的XYZControllerForEfficientHandlingOfStrings和另一處XZYControllerForEfficientStorageOfStrings,會花費很長時間

（3）做有意義的區分：如果程序員知識為了滿足編譯器或解釋器的需要而寫代碼，就會制造麻煩。例如因為同一范圍內兩樣不同的東西不能重名，你可能會隨手改掉其中一個名稱。有事干脆以錯誤的拼寫充數，結果就是出現在更正拼寫錯誤后導致編譯器出錯的情況。 光是添加數字系列或是廢話遠遠不夠，（a1,a2,a3）以數字命名不能提供正確的信息，不能提供導向作者的意圖的線索 廢話：假設你有一個PRoduct類，還有一個ProductInfo或者ProductData類，他們雖然名稱不同，意思卻無區別 廢話都是榮譽的。Table一次永遠不應該出現在表名中。NameString會比Name好嗎？難道姓名還能是浮點數？

（4）使用讀的出來的名稱：

（5）使用可搜索的名稱：單字母名稱和數字常量很難再一大篇文字中找出來。名稱長短應與其作用域大小相對。

（6）避免思維映射：不應該讓讀者在腦中把你的名稱翻譯為他們數值的名稱 （聰明程序員與專業程序員之間的區別在于，專業程序員了解：明確是王道）

（7）添加有意義的語境，不要添加沒有意義的語境