編寫高質(zhì)量的代碼,從命名入手
筆者從事開發(fā)多年,有這樣一種感覺,查看一些開源項目,如Spring、Apache Common等源碼是一件賞心悅目的事情,究其原因,無外兩點:1)代碼質(zhì)量非常高;2)命名特別規(guī)范(這可能跟老外的英語水平有關)。
要寫高質(zhì)量的代碼,不是一件容易的事,需要長年累月的鍛煉,是一個量變到質(zhì)變的過程,但要寫好命名,只需要有比較好的英語語法基礎和一種自我意識即可輕松達到。本博文將會結合本人的開發(fā)經(jīng)驗,總結出若干命名規(guī)則,這些命名規(guī)則純屬個人的使用習慣,不代表是一種理想的規(guī)則,在這里列舉出來,供大家交流討論。
1.切忌使用沒有任何意義的英語字母進行命名
for(int i=0; i<10; i++) {
...
}
這是在很多教Java基本語法的書上常見的代碼片斷,作為教學材料,這樣寫無可厚非,但作為真正的代碼編寫,程序員必須要養(yǎng)成良好的習慣,不要使用這種沒有任何含義的命名方式,這里可以使用“index”。
2.切忌使用拼音,甚至是拼音首字母組合
cishu =5; // 循環(huán)的次數(shù)
zzje = 1000.00 // 轉(zhuǎn)賬金額
筆者在做代碼檢查的時候,無數(shù)次遇到過這樣的命名,使人哭笑不得
3.要使用英文,而且要使用準確的英語,無論是拼寫還是語法
-
名詞單數(shù),必須使用單數(shù)英文,如Account、Customer。
-
對于數(shù)組,列表等對象集合的命名,必須使用復數(shù),而且***按照英文的語法基礎知識使用準確的復數(shù)形式,如 List<Account> accounts、Set<Strategy> strategies。
-
對于boolean值的屬性,很多開發(fā)人員習慣使用isXXX,如isClose(是否關閉),但這里有兩點建議:1)***不要帶“is”,因為 JavaBean的規(guī)范,為屬性生成get/set方法的時候,會用“get/set/is”,上面的例子,生成get/set方法就會變成 “getIsClose/isIsClose/getIsClose”,非常別扭;2)由于boolean值通常反映“是否”,所以準確的用法,應該是是 用“形容詞”,上面的例子,最終應該被改為 closed,那么get/set方法就是“getClosed/isColsed/setClosed”,非常符合英語閱讀習慣。
4.方法名的命名,需要使用“動賓結構短語”或“是動詞+表語結構短語”
筆者曾看到過千奇百怪的方法命名,有些使用名詞,有些甚至是“名詞+動詞”,而且,如果賓語是一個對象集合,還是***使用復數(shù):
createOrder(Order order) //good
orderCreate(Order order) //bad
removeOrders(List<Order> orders) //good
removeOrder(List<Order> order) //bad
5.對于常見的“增刪改查”方法,命名***要謹慎:
-
增加:最常見使用create和add,但***根據(jù)英語的語義進行區(qū)分,這有助于理解,create代表創(chuàng)建,add代表增加。比如,要創(chuàng)建一個 Student,用createStudent要比用addStudent好,為什么?想想如果有個類叫Clazz(班級,避開Java關鍵字),現(xiàn)在要 把一個Student加入到一個Clazz,Clazz很容易就定義了一個 addStudent(Student student)的方法,那么就比較容易混淆。
-
修改:常見的有alter、update、modify,個人覺得modify最準確。
-
查詢:對于獲取單個對象,可以用get或load,但個人建議用get,解釋請見第7點的說明,對于不分條件列舉,用list,對于有條件查詢, 用search(***不要用find,find在英文了強調(diào)結果,是“找到”的意思,你提供一個“查詢”方法,不保證輸入的條件總能“找到”結果)。
-
刪除:常見的有delete和remove,但刪除建議用delete,因為remove有“移除”的意思,參考Clazz的例子就可以理解,從班級移除一個學生,會用removeStudent。
6.寧愿方法名冗長,也不要使用讓人費解的簡寫
筆者曾經(jīng)遇到一個方法,判斷“支付賬戶是否與收款賬戶相同”,結果我看到一個這樣的命名:
checkIsOrderingAccCollAccSame(...) // 很難理解,我馬上把它改為:
isOrderingAccountSameAsCollectionAccount(...) // 雖然有點長,但非常容易閱讀,而且這種情況總是出現(xiàn)得比較少。
7.如果你在設計業(yè)務系統(tǒng),***不要使用技術化的術語去命名
筆者曾經(jīng)工作的公司曾經(jīng)制訂這樣的命名規(guī)則,接口必須要以“I”開頭,數(shù)據(jù)傳輸對象必須以“DTO”作為后綴,數(shù)據(jù)訪問對象必須以“DAO”作為后 綴,領域?qū)ο蟊仨氁?ldquo;DO”作為后綴,我之所以不建議這種做法,是希望設計人員從一開始就引導開發(fā)人員,要從“業(yè)務”出發(fā)考慮問題,而不要從“技術”出 發(fā)。
所以,接口不需要非得以“I”開頭,只要其實現(xiàn)類以“Impl”結尾即可(注:筆者認為接口是與細節(jié)無關的,與技術無關,但實現(xiàn)類是實現(xiàn)相關的,用 技術化術語無可口非),而數(shù)據(jù)傳輸對象,其實無非就是保存一個對象的信息,因此可以用“**Info”,如CustomerInfo,領域?qū)ο蟊旧砭褪菢I(yè) 務的核心,所以還是以其真實名稱出現(xiàn),比如Account、Customer,至于“DAO”,這一個詞來源于J2ee的設計模式,筆者在之前的項目使用“***Repository”命名,意味“***的倉庫”,如AccountRepository.
關于“Repository”這個詞的命名,是來源于Eric Evans的《Domain-Driven Design》一書的倉庫概念,Eric Evans對Repository的概念定義是:領域?qū)ο蟮母拍钚约希瑐€人認為這個命名非常的貼切,它讓程序員完全從技術的思維中擺脫出來,站在業(yè)務的 角度思考問題。說到這里,可能有人會反駁:像Spring、Hibernate這些優(yōu)秀的框架,不是都在用“I”作為接口開頭,用“DAO”來命名數(shù)據(jù)訪 問對象嗎?沒錯!但千萬別忽略了語義的上下文,Spring、Hibernate框架都是純技術框架,我這里所說的場景是設計業(yè)務系統(tǒng)。
8.成員變量不要重復類的名稱
例如,很多人喜歡在Account對象的成員變量中使用accountId,accountNumber等命名,其實沒有必要,想想成員變量不會鼓孤立的存在,你引用accountId,必須是account.accountId,用account.id已經(jīng)足夠清晰了。
“勿以善小而不為,勿以惡小而為之”、“細節(jié)決定成敗”,有太多的名言告訴我們,要注重細節(jié)。一個優(yōu)秀的程序員,必須要有堅實的基礎,而對于命名規(guī)則這樣容易掌握的基礎,我們何不現(xiàn)行?