怎么編寫高質量的web開發代碼

本文小編為大家詳細介紹“怎么編寫高質量的web開發代碼”，內容詳細，步驟清晰，細節處理妥當，希望這篇“怎么編寫高質量的web開發代碼”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

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已經足夠清晰了。

讀到這里，這篇“怎么編寫高質量的web開發代碼”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。