C# 標準命名規範

　筆者從事開發多年，有這樣一種感受，查看一些開源項目，如Spring、Apache Common等源碼是一件賞心悅目的事情，究其緣由，無外兩點：1）代碼質量很是高；2）命名特別規範（這可能跟老外的英語水平有關）。

　　要寫高質量的代碼，不是一件容易的事，須要終年累月的鍛鍊，是一個量變到質變的過程，但要寫好命名，只須要有比較好的英語語法基礎和一種自我意識便可輕鬆達到。本博文將會結合本人的開發經驗，總結出若干命名規則，這些命名規則純屬我的的使用習慣，不表明是一種理想的規則，在這裏列舉出來，供你們交流討論。

　　1. 切忌使用沒有任何意義的英語字母進行命名

for(int i=0; i<10; i++) {     //... }

　　這是在不少教Java基本語法的書上常見的代碼片段，做爲教學材料，這樣寫無可厚非，但做爲真正的代碼編寫，程序員必需要養成良好的習慣，不要使用這種沒有任何含義的命名方式，這裏可使用「index」。

　　2. 切忌使用拼音，甚至是拼音首字母組合

cishu =5;  // 循環的次數 zzje = 1000.00;  // 轉帳金額

　　筆者在作代碼檢查的時候，無數次遇到過這樣的命名，令人啼笑皆非。

　　3. 要使用英文，並且要使用準確的英語，不管是拼寫仍是語法

• 名詞單數，必須使用單數英文，如Account、Customer。
• 對於數組，列表等對象集合的命名，必須使用複數，並且最好按照英文的語法基礎知識使用準確的複數形式，如 List<Account> accounts、Set<Strategy> strategies。
• 對於boolean值的屬性，不少開發人員習慣使用isXXX，如isClose（是否關閉），但這裏有兩點建議：1）最好不要帶「is」，由於JavaBean的規範，爲屬性生成get/set方法的時候，會用「get/set/is」，上面的例子，生成get/set方法就會變成「getIsClose/isIsClose/getIsClose」，很是彆扭；2）因爲boolean值一般反映「是否」，因此準確的用法，應該是是用「形容詞」，上面的例子，最終應該被改成 closed，那麼get/set方法就是「getClosed/isColsed/setClosed」，很是符合英語閱讀習慣。

　　4. 方法名的命名，須要使用「動賓結構短語」或「是動詞+表語結構短語」

　　筆者曾看到過千奇百怪的方法命名，有些使用名詞，有些甚至是「名詞+動詞」，並且，若是賓語是一個對象集合，仍是最好使用複數。

createOrder(Order order) //good     orderCreate(Order order) //bad removeOrders(List<Order> orders) //good  removeOrder(List<Order> order) //bad

　　5. 對於常見的「增刪改查」方法，命名最好要謹慎

• 增長：最多見使用create和add，但最好根據英語的語義進行區分，這有助於理解，create表明建立，add表明增長。好比，要建立一個Student，用createStudent要比用addStudent好，爲何？想一想若是有個類叫Clazz(班級，避開Java關鍵字），如今要把一個Student加入到一個Clazz，Clazz很容易就定義了一個 addStudent（Student student)的方法，那麼就比較容易混淆。
• 修改：常見的有alter、update、modify，我的以爲modify最準確。
• 查詢：對於獲取單個對象，能夠用get或load，但我的建議用get，解釋請見第7點的說明；對於不分條件列舉，用list；對於有條件查詢，用search（最好不要用find，find在英文了強調結果，是「找到」的意思，你提供一個「查詢」方法，不保證輸入的條件總能「找到」結果）。
• 刪除：常見的有delete和remove，但刪除建議用delete，由於remove有「移除」的意思，參考Clazz的例子就能夠理解，從班級移除一個學生，會用removeStudent。

　　6. 寧願方法名冗長，也不要使用讓人費解的簡寫

　　筆者曾經遇到一個方法，判斷「支付帳戶是否與收款帳戶相同」，結果我看到一個這樣的命名：

checkIsOrderingAccCollAccSame(...)

　　很難理解，我立刻把它改成：

isOrderingAccountSameAsCollectionAccount(...)

　　雖然有點長，但很是容易閱讀，並且這種狀況老是出現得比較少。

　　7. 若是你在設計業務系統，最好不要使用技術化的術語去命名

　　筆者曾經工做的公司曾經制訂這樣的命名規則，接口必需要以「I」開頭，數據傳輸對象必須以「DTO」做爲後綴，數據訪問對象必須以「DAO」做爲後綴，領域對象必須以「DO」做爲後綴。我之因此不建議這種作法，是但願設計人員從一開始就引導開發人員，要從「業務」出發考慮問題，而不要從「技術」出發。因此，接口不須要非得以「I」開頭，只要其實現類以「Impl」結尾便可（注：筆者認爲接口是與細節無關的，與技術無關，但實現類是實現相關的，用技術化術語無可口非）；而數據傳輸對象，其實無非就是保存一個對象的信息，所以能夠用「**Info」，如CustomerInfo；領域對象自己就是業務的核心，因此仍是以其真實名稱出現，好比Account、Customer；至於「DAO」，這一個詞來源於J2ee的設計模式，筆者在以前的項目使用「***Repository」命名，意味「***的倉庫」，如AccountRepository，關於「Repository」這個詞的命名，是來源於Eric Evans的《Domain-Driven Design》一書的倉庫概念，Eric Evans對Repository的概念定義是：領域對象的概念性集合，我的認爲這個命名很是的貼切，它讓程序員徹底從技術的思惟中擺脫出來，站在業務的角度思考問題。說到這裏，可能有人會反駁：像Spring、Hibernate這些優秀的框架，不是都在用「I」做爲接口開頭，用「DAO」來命名數據訪問對象嗎？沒錯！但千萬別忽略了語義的上下文，Spring、Hibernate框架都是純技術框架，我這裏所說的場景是設計業務系統。

　　8. 成員變量不要重複類的名稱

　　例如，不少人喜歡在Account對象的成員變量中使用accountId，accountNumber等命名，其實沒有必要，想一想成員變量不會鼓孤立的存在，你引用accountId，必須是account.accountId，用account.id已經足夠清晰了。

　　「勿以善小而不爲，勿以惡小而爲之」、「細節決定成敗」，有太多的名言告訴咱們，要注重細節。一個優秀的程序員，必需要有堅實的基礎，而對於命名規則這樣容易掌握的基礎，咱們何不現行？