<讀書筆記> 代碼整潔之道
概述
本文引用地址:http://www.ex-cimer.com/article/201608/294841.htm1、本文檔的內容主要來源于書籍《代碼整潔之道》作者Robert C.Martin,屬于讀書筆記。
2、軟件質量,不僅依賴于架構和項目管理,而且與代碼質量緊密相關,本書提出一種,代碼質量與整潔成正比的觀點,并給出了一系列行之有效的整潔代碼操作實踐,只要遵循這些規(guī)則,就可以編寫出整潔的代碼,從而提升代碼質量。
3、該書介紹的規(guī)則均來自于作者多年的實踐經(jīng)驗,涵蓋從命名到重構的多個編程方面,具有很好的學習和借鑒價值。
4、習藝要有二:知和行。你應當學習有關規(guī)則、模式和實踐的知識,窮盡應知之事,并且對其了如指掌,通過刻苦實踐掌握它!
前言
學習整潔代碼很難,它不止于要求你掌握原則和模式,你還得在上面下功夫,并自行實踐,體驗失敗。你須觀察他人如何實踐與失敗,怎樣蹣跚學步,再轉頭學習他們的路數(shù),。
本書要求你多用信息,多用功,而且非常用功。如何用功?-大量閱讀代碼,并琢磨代碼好在什么地方,壞在什么地方。
本書大概分為三部分:原則、模式和實踐。
一、 使用有意義的命名
1、名副其實
注意命名,一旦發(fā)現(xiàn)有更好的名稱就換掉舊的,這么做閱讀的人會更開心
名稱本身應該能解釋其含義,無需注釋就能看懂是最佳。比如
int d;//消失時間,以日計
int elapsedTimeInDays;
前者名稱沒有任何含義,在程序中使用時看不出這個變量的實際作用,需要對應注釋才能看懂,因此遠不如后者的名稱好!
2、避免誤導
程序員必須避免留下掩藏代碼本意的錯誤線索,避免使用與本意相悖的詞。
提防使用細節(jié)之處差別較小的名稱
使用相同的拼寫方式,前后拼寫不一致(大小寫不同),就是誤導。在使用編輯器名稱自動補全功能時,拼寫相近的變量容易引起誤選。
避免使用小寫字母l和大寫字母O作為變量名稱,易與1和0混淆
3、做有意義的區(qū)分
避免以數(shù)字系列命名,其無法提供正確的信息和導向作者意圖的線索。
不要使用意義相近的名稱,比如ProductInfo和ProductData變量不同,意思一樣,容易引起意義混淆
不要使用冗余信息,比如NameString,難道Name會是一個浮點數(shù)嗎?如果是,就不該使用Name命名。
4、使用讀的出來的名稱
人類善于記憶和使用單詞,如果名稱無法閱讀或者發(fā)音,就不是一個好名稱,討論和交流時也難以表達。
比如函數(shù)名稱為:genymdhms()//生成日期,年月日時分秒。
不要使用傻乎乎的自造詞,而要使用恰當?shù)挠⒄Z單詞
5、使用可搜索的名稱
比如字母e,f等就不是一個好的變量名,其是英文常用字母,不方便搜索,
單字母名稱僅限于本地局部變量使用,名稱長短應該與作用域大小相對應
如果程序中多出使用相同數(shù)字,實現(xiàn)相同功能,則需要使用宏定義變量代替。
比如WORK_DAYS_PER_WEEK就比數(shù)字5好搜索,也更能體現(xiàn)作者意圖
6、避免使用編碼
無需把類型和作用域編進名稱,這樣只會自找麻煩,既不便發(fā)音,也容易拼錯,對解決問題毫無幫助。
匈牙利標記法,破壞了不編碼的規(guī)則,不應該采用。
也不必使用成員前綴,應該把類和函數(shù)做的足夠小,同時使用可以高亮和顏色標出成員的編輯環(huán)境。(Keil,notepad++都支持)。
7、避免思維映射
不應當讓讀者把你腦中的名稱翻譯成他們熟知的名稱,這個問題常見于選擇使用問題領域的術語還是解決方案領域的術語時。
在作為局部變量時,并且名稱沒有沖突時,可以采用i,j,k作為循環(huán)變量。
專業(yè)程序員善用其能,編寫能讓他人理解的代碼
8、類名
類名應該是名稱或者名詞短語,例如Customer、Account,避免使用Manager、Data、Info這樣的類名,其不應該是動詞。
9、方法名
方法名應該是動詞或者動詞短語,比如postPayment、deletePage或s**e,屬性訪問應該加上set、get、is前綴
10、每個概念對應一個詞
給每個抽象概念選用一個詞,并且一以貫之。比如使用fetch、retrieve、get在多個類的中同種方法命名,就容易引起混淆。
11、別用雙關語
避免將以此用于不同目的,同一術語用于不同概念就是雙關語了。
比如多個類中都有add方法,該方法通過增加或者鏈接兩個現(xiàn)存值來獲得新值,如果一個新類的含義是,把單個參數(shù)放到群集(collection)中,使用add名稱,雖然保持了名稱一致,你是含義卻不同,應該使用insert才對。
12、使用解決方案領域的名稱
因為只有程序員才會讀取你的代碼,因此名稱應該選擇解決方案領域的名稱,而不是問題設計領域的名稱。比如名稱AccountVisitor就比JobQueue富有意義。
13、使用源自所涉及問題領域的名稱
當不能使用程序員所熟悉的術語命名時,就應該采用所涉及問題領域的名稱
與所涉問題領域更加貼近的代碼,應當采用源自問題領域的名稱
14、添加有意義的語境
很少有名稱能夠自我說明-多數(shù)都不能,因此需要使用良好命名的類、函數(shù)來放置名稱,給讀者提供語境。
比如添加前綴addrFirstName、addrLastName、addrState,就可以提供語境,這些變量屬于地址范圍。更好的做法是,創(chuàng)建一個名稱為Address的類,來存放這些相關變量。
語境的增強也讓算法能夠通過分解為更小的函數(shù)而變得干凈利索。
15、不要添加沒有意義的語境
比如應用(Gas Station Deluxe)簡稱為GSD,因此為每個函數(shù)、類、變量增加同樣的前綴就GSD命名就不是一個好點子。
Address是個好名稱,但是如果需要與MAC地址、端口地址或Web地址區(qū)分,應當使用PostalAddress、MAC、URI,這樣的名稱更為精確。
16、總結
取名字最難地方在于需要良好的描述技巧和共有的文化背景
試試上面的規(guī)則,看你的代碼的可讀性是否有所提升。如果維護別人的代碼,使用重構工具來解決問題,效果也好立竿見影,而且會持續(xù)下去。
評論