解讀《阿里巴巴Java開發手冊》（泰山版) - 更新中

前言

《阿里巴巴Java開發手冊》一直深受Java開發愛好者和業界人士的承認，裏面提出了許多寶貴的開發經驗和建議，相信會對你們有不少的幫助。

可是所謂盡信書不如無書，須要對提到的規範有本身的思考和認同後，這本手冊纔可以對本身起到更大的幫助。

小弟不才，只是從我的觀點談談對於這本手冊閱讀的理解，指望能夠持續更新。

編程規約篇

命名風格

1.【強制】代碼中的命名均不能如下劃線或美圓符號開始，也不能如下劃線或美圓符號結束。

贊同，能夠強制遵照。首先實際代碼開發時確實能夠這樣去作，但這條規範應該是業內同行的共識了，並且如下劃線和美圓符號開始和結束並不會帶來什麼其餘的好處。

2.【強制】全部編程相關的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。

贊同，能夠強制遵照。用純英文表達釋義更容易理解，拼音或者拼音與英文結合，還要考慮多音字的可能性，也不太好理解。

3.【強制】類名使用UpperCamelCase風格，但如下情形例外:DO/BO/DTO/VO/AO/ PO / UID 等。

贊同，能夠強制遵照。駝峯式命名這個基本已是共識了，但關於DO,BO等，其實項目中有人喜歡寫Bo,有人先寫BO,我我的感受更傾向於兩個都大寫，這些實際上是一些專用術語的縮寫，因此都大寫是比較合適的，好比DTO，實際上是 Data Transfer Object的縮寫。

4.【強制】方法名、參數名、成員變量、局部變量都統一使用lowerCamelCase風格。

贊同，能夠強制遵照。基本都是業內共識了。

1. 【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。

贊同，能夠強制遵照。所有大寫，單詞間下劃線隔開，基本都是共識了，看到過部分代碼由於考慮到長度問題，使用了一些縮寫來表達，我我的不是很喜歡，屬於寧肯長一些，但更喜歡可讀性強一些的開發者。

1. 【強制】抽象類命名使用Abstract或Base開頭;異常類命名使用Exception結尾;測試類 命名以它要測試的類的名稱開始，以 Test 結尾。

贊同，能夠強制遵照。這樣理解會更加清晰一些。

1. 【強制】類型與中括號緊挨相連來表示數組。

贊同，能夠強制遵照。這樣看起來會更加的直觀清晰，手冊中提到的反例是 在main函數的入參中，使用String args[]來定義。我看了下目前IDEA在自動生成main函數時已是String[] args這種風格了。

1. 【強制】POJO類中的任何布爾類型的變量，都不要加is前綴，不然部分框架解析會引發序列 化錯誤。

有待考究，待補充，手冊中給的反例是定義爲基本數據類型 Boolean isDeleted的屬性，方法也是isDeleted()，框架在反向解析時，會覺得對應的屬性名稱是deleted，致使屬性獲取不到，進而拋出異常。

那麼是哪些框架會出現這些問題呢，如今是否仍然有這些問題，這個有必定歷史感的規範是否仍要遵照，畢竟我以爲加上is後，若是是布爾類型，我會更好理解一些，也能夠和數據庫中的命名一一對應。

9.【強制】包名統一使用小寫，點分隔符之間有且僅有一個天然語義的英語單詞。包名統一使用 單數形式，可是類名若是有複數含義，類名可使用複數形式。

到類名以前的部分贊同，能夠強制遵照。 關於類名有複數含義，能夠用複數形式，這個困擾的主要是爲何類名會有複數含義呢，類表明的應該就是一個功能和屬性的集合，按個人理解來講，應該是不具有複數含義的。

10.【強制】避免在子父類的成員變量之間、或者不一樣代碼塊的局部變量之間採用徹底相同的命名，使可讀性下降。

基本贊同，能夠遵照，若是是表明同一個意思，用一個變量名錶達，可讀性會更好，管理維護也在一處地方。