代碼整潔之道，Clean Code，作者是美國的Robert C.Martin，寫這個我只是為了提高這本書的格調~~
這本書是我前一段時間讀的，讀過之后對我編程有很大的影響，建議程序員同志們閱讀一下。簡單說一下我從里面收獲的最重要的觀點，做個簡單的書摘，歡迎討論~~
1. 有意義的命名
這個對于程序員來說并不陌生，但是什么樣才算做有意義書里進行了詳細的講解。
（1）避免誤導：比如accountList表示一組賬號，如果它并不是List類型，那么就會引起錯誤的判斷，因為List對程序員來說是一個特殊的類。
（2）沒有廢話、不冗余：比如Variable永遠不應該出現在變量名之中。
（3）讀起來清晰易懂：比如某家公司中有genymdhms這樣一個函數（表示生成日期、年、月、日、時、分、秒），讀起來晦澀，簡直是糟糕的命名方式。
（4）便于搜索：比如某個變量表示一周的天數，用7這個數字遠遠不如定義一個A_WEEK_DAYS這樣的常量容易被搜索到進行修改或者查詢。
（5）命名增加變量類型：比如String strTemperature中的str表示變量類型，這個在實際閱讀過程中會被忽略，在編程過程中也并沒有起到很好的作用，反而增加了修改代碼的難度和閱讀代碼的難度。這里我個人經常寫android的時候這樣用，主要是用于區分控件，因為一個界面的控件名比較容易重復，所以我個人覺得如果從命名區分的角度來講還是可以加類型的。
（6）符合普遍思維，不用雙關語：比如add、insert、append之間的區別要搞清楚，對于方法的命名要清晰。
2. 函數
函數的寫法和命名是決定這整個程序是否易讀的關鍵點。
（1）短小：曾經說函數不應該超過一屏，后來說20行封頂最佳，實際上一個函數應該做的就是做一層的工作，相當于一個while，或者一個if、else結構，要縮到最短才是合格的函數。當然比如說像android中findviewbyid()這種需要大量copy的代碼，自然要很多行，其實文中的意思是要縮短一個函數的邏輯長度，所以對于邏輯函數應該不超過10行左右。
（2）只做一件事：比如顯示一個手機屏幕上的控件函數，需要顯示所有的TextView和所有的Button，那么這就是兩件事兒，要分成兩個函數來寫，不能混在一起。
（3）函數參數：最理想的是零參數函數，其次是一，再次是二，應盡量避免三，有足夠特殊的理由才能使用三個以上參數。主要原因在于，一旦有參數就需要你了解函數更多地細節，從測試的角度來說更叫人為難，參數越多測試用例越復雜。
（4）標識參數：標志參數丑陋不堪，向函數傳入布爾值簡直就是駭人聽聞的做法。這樣做大聲宣布函數不止做一件事，違反了第二條，應該將其分為兩個函數分別調用。
（5）參數對象：如果函數看來需要兩個、三個或三個以上參數，說明其中一些參數應該封裝為類了。
（6）使用異常代替返回錯誤碼：不要用一層層的if、else在不同的情況去輸出不同的錯誤碼，而應該用異常直接獲取錯誤，代碼整體立馬簡潔易讀。
（7）錯誤處理就是一件事：因為函數應該只做一件事，所以錯誤處理就是一件事。
放個圖，解釋一下什么叫做簡潔的函數：
3. 注釋
文中有一個對于注釋非常鮮明的觀點，這句話是這樣的：注釋的恰當用法是彌補我們在用代碼表達意圖時遭遇的失??！注釋是一種失??！因為找不到不用注釋表達自我的方法，所以要有注釋，這并不值得慶賀。
為什么要極力貶低注釋？因為注釋會撒謊，注釋存在的時間越久，離其所描述的代碼越遠，越來越變得全然錯誤，原因就是程序員不能堅持維護注釋。比如我自己代碼中的一個例子：
注釋不能美化糟糕的代碼
用代碼來闡述不要用注釋
下面講講好注釋都可能有哪些：
（1）法律信息，不過更好的是指向一份標準許可或者其他文檔；
（2）表示返回值含義，不過其實也可以用函數命名來彌補；
（3）或者解釋某種臨時的解決方案；
（4）警示使用該代碼的后果；
（5）todo注釋，表示應該做但是還沒做的事情，但是這是必須立刻解決掉的注釋。
再帶大家看看壞注釋都有什么。
（1）喃喃自語。。。
（2）多余的注釋，如下圖，讀這段注釋花的時間沒準比讀代碼花的時間還要長
（3）循規式注釋，如下圖，非要給函數加上注釋解釋變量含義。
（4）日志式注釋，如下圖，在已經有源代碼控制系統可用的今天，這種冗長的記錄只會讓模塊變得凌亂不堪，應當全部刪除
（5）廢話注釋：如下圖，不多說了，看看就懂了
（6）歸屬與署名：比如在代碼中標注了哪里是自己修改的
（7）注釋掉的代碼：其他人不敢刪，只會長期堆積，變成一堆垃圾
我可以說我看完這篇之后，就基本很少寫注釋了。
