<讀書筆記> 代碼整潔之道

　　概述

本文引用地址：http://www.eepw.com.cn/article/201608/294841.htm

　　1、本文檔的內容主要來源於書籍《代碼整潔之道》作者Robert C.Martin，屬於讀書筆記。

　　2、軟體質量，不僅依賴於架構和項目管理，而且與代碼質量緊密相關，本書提出一種，代碼質量與整潔成正比的觀點，並給出了一系列行之有效的整潔代碼操作實踐，只要遵循這些規則，就可以編寫出整潔的代碼，從而提升代碼質量。

　　3、該書介紹的規則均來自於作者多年的實踐經驗，涵蓋從命名到重構的多個編程方面，具有很好的學習和借鑑價值。

　　4、習藝要有二：知和行。你應當學習有關規則、模式和實踐的知識，窮盡應知之事，並且對其了如指掌，通過刻苦實踐掌握它!

　　前言

　　學習整潔代碼很難，它不止於要求你掌握原則和模式，你還得在上面下功夫，並自行實踐，體驗失敗。你須觀察他人如何實踐與失敗，怎樣蹣跚學步，再轉頭學習他們的路數，。

　　本書要求你多用信息，多用功，而且非常用功。如何用功?-大量閱讀代碼，並琢磨代碼好在什麼地方，壞在什麼地方。

　　本書大概分為三部分：原則、模式和實踐。

　　一、 使用有意義的命名

　　1、名副其實

　　注意命名，一旦發現有更好的名稱就換掉舊的，這麼做閱讀的人會更開心

　　名稱本身應該能解釋其含義，無需注釋就能看懂是最佳。比如

　　int d;//消失時間，以日計

　　int elapsedTimeInDays;

　　前者名稱沒有任何含義，在程序中使用時看不出這個變量的實際作用，需要對應注釋才能看懂，因此遠不如後者的名稱好!

　　2、避免誤導

　　程式設計師必須避免留下掩藏代碼本意的錯誤線索，避免使用與本意相悖的詞。

　　提防使用細節之處差別較小的名稱

　　使用相同的拼寫方式，前後拼寫不一致(大小寫不同)，就是誤導。在使用編輯器名稱自動補全功能時，拼寫相近的變量容易引起誤選。

　　避免使用小寫字母l和大寫字母O作為變量名稱，易與1和0混淆

　　3、做有意義的區分

　　避免以數字系列命名，其無法提供正確的信息和導向作者意圖的線索。

　　不要使用意義相近的名稱，比如ProductInfo和ProductData變量不同，意思一樣，容易引起意義混淆

　　不要使用冗餘信息，比如NameString，難道Name會是一個浮點數嗎?如果是，就不該使用Name命名。

　　4、使用讀的出來的名稱

　　人類善於記憶和使用單詞，如果名稱無法閱讀或者發音，就不是一個好名稱，討論和交流時也難以表達。

　　比如函數名稱為：genymdhms()//生成日期，年月日時分秒。

　　不要使用傻乎乎的自造詞，而要使用恰當的英語單詞

　　5、使用可搜索的名稱

　　比如字母e,f等就不是一個好的變量名，其是英文常用字母，不方便搜索，

　　單字母名稱僅限於本地局部變量使用，名稱長短應該與作用域大小相對應

　　如果程序中多出使用相同數字，實現相同功能，則需要使用宏定義變量代替。

　　比如WORK_DAYS_PER_WEEK就比數字5好搜索，也更能體現作者意圖

　　6、避免使用編碼

　　無需把類型和作用域編進名稱，這樣只會自找麻煩，既不便發音，也容易拼錯，對解決問題毫無幫助。

　　匈牙利標記法，破壞了不編碼的規則，不應該採用。

　　也不必使用成員前綴，應該把類和函數做的足夠小，同時使用可以高亮和顏色標出成員的編輯環境。(Keil，notepad++都支持)。

　　7、避免思維映射

　　不應當讓讀者把你腦中的名稱翻譯成他們熟知的名稱，這個問題常見於選擇使用問題領域的術語還是解決方案領域的術語時。

　　在作為局部變量時，並且名稱沒有衝突時，可以採用i,j,k作為循環變量。

　　專業程式設計師善用其能，編寫能讓他人理解的代碼

　　8、類名

　　類名應該是名稱或者名詞短語，例如Customer、Account,避免使用Manager、Data、Info這樣的類名，其不應該是動詞。

　　9、方法名

　　方法名應該是動詞或者動詞短語，比如postPayment、deletePage或s**e,屬性訪問應該加上set、get、is前綴

　　10、每個概念對應一個詞

　　給每個抽象概念選用一個詞，並且一以貫之。比如使用fetch、retrieve、get在多個類的中同種方法命名，就容易引起混淆。

　　11、別用雙關語

　　避免將以此用於不同目的，同一術語用於不同概念就是雙關語了。

　　比如多個類中都有add方法，該方法通過增加或者連結兩個現存值來獲得新值，如果一個新類的含義是，把單個參數放到群集(collection)中,使用add名稱，雖然保持了名稱一致，你是含義卻不同，應該使用insert才對。

　　12、使用解決方案領域的名稱

　　因為只有程式設計師才會讀取你的代碼，因此名稱應該選擇解決方案領域的名稱，而不是問題設計領域的名稱。比如名稱AccountVisitor就比JobQueue富有意義。

　　13、使用源自所涉及問題領域的名稱

　　當不能使用程式設計師所熟悉的術語命名時，就應該採用所涉及問題領域的名稱

　　與所涉問題領域更加貼近的代碼，應當採用源自問題領域的名稱

　　14、添加有意義的語境

　　很少有名稱能夠自我說明-多數都不能，因此需要使用良好命名的類、函數來放置名稱，給讀者提供語境。

　　比如添加前綴addrFirstName、addrLastName、addrState，就可以提供語境，這些變量屬於地址範圍。更好的做法是，創建一個名稱為Address的類，來存放這些相關變量。

　　語境的增強也讓算法能夠通過分解為更小的函數而變得乾淨利索。

　　15、不要添加沒有意義的語境

　　比如應用(Gas Station Deluxe)簡稱為GSD,因此為每個函數、類、變量增加同樣的前綴就GSD命名就不是一個好點子。

　　Address是個好名稱，但是如果需要與MAC地址、埠地址或Web地址區分，應當使用PostalAddress、MAC、URI，這樣的名稱更為精確。

　　16、總結

　　取名字最難地方在於需要良好的描述技巧和共有的文化背景

　　試試上面的規則，看你的代碼的可讀性是否有所提升。如果維護別人的代碼，使用重構工具來解決問題，效果也好立竿見影，而且會持續下去。