Java開發都須要參考的一份命名規範

每一個公司都有不一樣的標準，目的是爲了保持統一，減小溝通成本，提高團隊研發效能。因此本文中是筆者結合阿里巴巴開發規範，以及工做中的見聞針對Java領域相關命名進行整理和總結，僅供參考。

Java中的命名規範

好的命名能體現出代碼的特徵，含義或者是用途，讓閱讀者能夠根據名稱的含義快速釐清程序的脈絡。不一樣語言中採用的命名形式截然不同，Java中經常使用到的命名形式共有三種，既首字母大寫的UpperCamelCase，首字母小寫的lowerCamelCase以及所有大寫的並用下劃線分割單詞的UPPERCAMELUNSER_SCORE。一般約定，類通常採用大駝峯命名，方法和局部變量使用小駝峯命名，而大寫下劃線命名一般是常量和枚舉中使用。

包命名

包名統一使用小寫，點分隔符之間有且僅有一個天然語義的英文單詞或者多個單詞天然鏈接到一塊（如 springframework，deepspace不須要使用任何分割）。包名統一使用單數形式，若是類命有複數含義，則可使用複數形式。

包名的構成能夠分爲如下幾四部分【前綴】 【發起者名】【項目名】【模塊名】。常見的前綴能夠分爲如下幾種：

類命名

類名使用大駝峯命名形式，類命一般時名詞或名詞短語，接口名除了用名詞和名詞短語之外，還可使用形容詞或形容詞短語，如Cloneable，Callable等，表示實現該接口的類有某種功能或能力。對於測試類則以它要測試的類開頭，以Test結尾，如HashMapTest。

對於一些特殊特有名詞縮寫也可使用全大寫命名，好比XMLHttpRequest，不過筆者認爲縮寫三個字母之內都大寫，超過三個字母則按照要給單詞算。這個沒有標準如阿里巴巴中fastjson用JSONObject做爲類命，而google則使用JsonObjectRequest命名，對於這種特殊的縮寫，原則是統一就好。

方法

方法命名採用小駝峯的形式，首字小寫，日後的每一個單詞首字母都要大寫。和類名不一樣的是，方法命名通常爲動詞或動詞短語，與參數或參數名共同組成動賓短語，即動詞 + 名詞。一個好的函數名通常能經過名字直接獲知該函數實現什麼樣的功能。

返回真僞值的方法

注：pre- prefix前綴，suf- suffix後綴，alo-alone 單獨使用

用來檢查的方法

按需求才執行的方法

異步相關方法

回調方法

操做對象生命週期的方法

與集合操做相關的方法

與數據相關的方法

成對出現的動詞

變量&常量命名

變量命名

變量是指在程序運行中能夠改變其值的量，包括成員變量和局部變量。變量名由多單詞組成時，第一個單詞的首字母小寫，其後單詞的首字母大寫，俗稱駱駝式命名法（也稱駝峯命名法），如 computedValues，index、變量命名時，儘可能簡短且能清楚的表達變量的做用，命名體現具體的業務含義便可。

變量名不該如下劃線或美圓符號開頭，儘管這在語法上是容許的。變量名應簡短且富於描述。變量名的選用應該易於記憶，即，可以指出其用途。儘可能避免單個字符的變量名，除非是一次性的臨時變量。pojo中的布爾變量，都不要加is(數據庫中的布爾字段全都要加 is_ 前綴)。

常量命名

常量命名CONSTANT_CASE，通常採用所有大寫（做爲方法參數時除外），單詞間用下劃線分割。那麼什麼是常量呢？

常量是在做用域內保持不變的值，通常使用final進行修飾。通常分爲三種，全局常量（public static final修飾），類內常量（private static final 修飾）以及局部常量（方法內，或者參數中的常量），局部常量比較特殊，一般採用小駝峯命名便可。

常量通常都有本身的業務含義,不要懼怕長度過長而進行省略或者縮寫。如，用戶消息緩存過時時間的表示，那種方式更佳清晰，交給你來評判。

通用命名規則

儘可能不要使用拼音；杜絕拼音和英文混用。對於一些通用的表示或者難以用英文描述的能夠採用拼音，一旦採用拼音就堅定不能和英文混用。正例：BeiJing， HangZhou 反例：validateCanShu

• 命名過程當中儘可能不要出現特殊的字符，常量除外。
• 儘可能不要和jdk或者框架中已存在的類重名，也不能使用java中的關鍵字命名。
• 妙用介詞，如for(能夠用同音的4代替), to(可用同音的2代替), from, with，of等。如類名採用User4RedisDO，方法名getUserInfoFromRedis，convertJson2Map等。

代碼註解

註解的原則

好的命名增長代碼閱讀性，代碼的命名每每有嚴格的限制。而註解不一樣，程序員每每能夠自由發揮，單並不意味着能夠隨心所欲之胡做非爲。優雅的註解一般要知足三要素。

Nothing is strange 沒有註解的代碼對於閱讀者很是不友好，哪怕代碼寫的在清除，閱讀者至少從心理上會有抵觸，更況且代碼中每每有許多複雜的邏輯，因此必定要寫註解，不只要記錄代碼的邏輯，還有說清楚修改的邏輯。

Less is more 從代碼維護角度來說，代碼中的註解必定是精華中的精華。合理清晰的命名能讓代碼易於理解，對於邏輯簡單且命名規範，可以清楚表達代碼功能的代碼不須要註解。濫用註解會增長額外的負擔，更況且大部分都是廢話。

// 根據id獲取信息【廢話註解】getMessageById(id)

Advance with the time 註解應該隨着代碼的變更而改變，註解表達的信息要與代碼中徹底一致。一般狀況下修改代碼後必定要修改註解。

註解格式

註解大致上能夠分爲兩種，一種是javadoc註解，另外一種是簡單註解。javadoc註解能夠生成JavaAPI爲外部用戶提供有效的支持javadoc註解一般在使用IDEA，或者Eclipse等開發工具時均可以自動生成，也支持自定義的註解模板，僅須要對對應的字段進行解釋。參與同一項目開發的同窗，儘可能設置成相同的註解模板。

包註解

包註解在工做中每每比較特殊，經過包註解能夠快速知悉當前包下代碼是用來實現哪些功能，強烈建議工做中加上，尤爲是對於一些比較複雜的包，包註解通常在包的根目錄下，名稱統一爲package-info.java。

/** 
* 落地也質量檢測 
* 1. 用來解決什麼問題 
* 對廣告主投放的廣告落地頁進行性能檢測，模擬不一樣的系統，如Android，IOS等; 模擬不一樣的網絡：2G，3G，4G，wifi等 
* 2. 如何實現 
* 基於chrome瀏覽器，用chromedriver驅動瀏覽器，設置對應的網絡，OS參數，獲取到瀏覽器返回結果。 
* 注意：網絡環境配置信息{@link cn.mycookies.landingpagecheck.meta.NetWorkSpeedEnum}目前使用是常規速度，能夠根據實際狀況進行調整 
* @author cruder 
* @time 2019/12/7 20:3 下午 
*/
package cn.mycookies.landingpagecheck;
複製代碼

類註解

javadoc註解中，每一個類都必須有註解。

屬性註解

在每一個屬性前面必須加上屬性註釋，一般有一下兩種形式，至於怎麼選擇，你高興就好，不過一個項目中要保持統一。

方法註釋

在每一個方法前面必須加上方法註釋，對於方法中的每一個參數，以及返回值都要有說明。

構造方法註釋

在每一個構造方法前面必須加上註釋，註釋模板以下：

注意事項

而簡單註解每每是須要工程師字節定義，在使用註解時應該注意一下幾點：

枚舉類的各個屬性值都要使用註解，枚舉能夠理解爲是常量，一般不會發生改變，一般會被在多個地方引用，對枚舉的修改和添加屬性一般會帶來很大的影響。

保持排版整潔，不要使用行尾註釋；雙斜槓和星號以後要用1個空格分隔。

---

寫做不易，若是文章對你有幫助，能否留下腳印留個贊~