本博整合阿里巴巴編碼規範自己所需，侵刪。
一、編碼規約
（一）命名風格
2. 【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式
3. 【強制】類名使用 UpperCamelCase 風格，但以下情形例外：DO / BO / DTO / VO / AO/ PO / UID 等。
正例：JavaServerlessPlatform / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：javaserverlessplatform / UserDo / XMLService / TCPUDPDeal / TAPromotion
4. 【強制】方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須遵從駝峯形式。
5. 【強制】常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。
正例：MAX_STOCK_COUNT / CACHE_EXPIRED_TIME
反例：MAX_COUNT / EXPIRED_TIME
6. 【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類命名以它要測試的類的名稱開始，以 Test 結尾。
7. 【強制】聲明數組時 []應與類型緊鄰，如：int[] arr;禁止使用int arr[]
8. 【強制】在entity和dto中布爾型變量禁止聲明爲isXXXX，直接使用XXXX的形式，比如，不能使用isDeleted，應使用deleted形式
9. 【強制】包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用單數形式，但是類名如果有複數含義，類名可以使用復 數形式。此處同樣禁止使用拼音與英文混合的方式，同樣不能使用中文。
正例：應用工具類包名爲 com.alibaba.ai.util、類名爲 MessageUtils（此規則參考 spring 的框架結構）
10. 【強制】避免在子父類的成員變量之間、或者不同代碼塊的局部變量之間採用完全相同的命名，使可讀性降低。即子父類成爲變量要加以區分。
11. 【強制】杜絕完全不規範的縮寫，避免望文不知義。禁止在代碼中隨意使用縮寫
12. 【強制】爲了達到代碼自解釋的目標，在自定義命名時，使用完整的單詞組合來表達其意。，注意拼寫檢查，單詞不要寫錯。如 int number，不可 以隨便命名a 或者寫成 nmuber。
16. 接口和實現類的命名有兩套規則：
1）【強制】對於 Service 和 DAO 類，基於 SOA 的理念，暴露出來的服務一定是接口，內部的實現類用Impl 的後綴與接口區別
18. 【強制】各層命名規約：
A) Service/DAO 層方法命名規約
1） 獲取單個對象的方法用 get 做前綴。
2） 獲取多個對象的方法用 list 做前綴，複數形式結尾如：listObjects。
3） 獲取統計值的方法用 count 做前綴。
4） 插入的方法用 save 做前綴。
5） 刪除的方法用 delete 做前綴。
6） 修改的方法用 update 做前綴。
13. 【推薦】在常量與變量的命名時，表示類型的名詞放在詞尾，提升辨識度。如userList，不要用listUser，用threadCount， 不要countThread
14. 【推薦】如果模塊、接口、類、方法使用了設計模式，在命名時需體現出具體模式。
說明：將設計模式體現在名字中，有利於閱讀者快速理解架構設計理念。
15. 【推薦】接口類中的方法和屬性不要加任何修飾符號（public 也不要加），並加上有效的 Javadoc 註釋。接口中儘量不要定義變量。
（二）常量定義
1. 【強制】不允許任何魔法值 （ 即未經預先定義的常量 ） 直接出現在代碼中。
反例：String key = "Id#taobao_" + tradeId;
cache.put(key, value);
// 緩存 get 時，由於在代碼複製時，漏掉下劃線，導致緩存擊穿而出現問題
2. 【強制】在 long 或者 Long 賦值時，數值後使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混淆，造成誤解。
3. 【強制】不要使用一個常量類維護所有常量，要按常量功能進行歸類，分開維護。
4. 【強制】常量的定義要放到constant包裏
1） 跨應用共享常量：放置在二方庫中，通常是 client.jar 中的 constant 目錄下。
2） 應用內共享常量：放置在一方庫中，通常是子模塊中的 constant 目錄下。
反例：易懂變量也要統一定義成應用內共享常量，兩位工程師在兩個類中分別定義了“YES”的變量：
類 A 中：public static final String YES = "yes";
類 B 中：public static final String YES = "y";
A.YES.equals(B.YES)，預期是 true，但實際返回爲 false，導致線上問題。
3） 子工程內部共享常量：即在當前子工程的 constant 目錄下。
4） 包內共享常量：即在當前包下單獨的 constant 目錄下。
5） 類內共享常量：直接在類內部 private static final 定義。
（三）代碼格式
1. 【強制】如果是大括號內爲空，則簡潔地寫成{}即可，大括號中間無需換行和空格；如果是非空代碼塊則：
1） 左大括號前不換行。
2） 左大括號後換行。
3） 右大括號前換行。
4） 右大括號後還有 else 等代碼則不換行；表示終止的右大括號後必須換行。
2. 【強制】左小括號和字符之間不出現空格 ； 同樣，右小括號和字符之間也不出現空格；而左大括號前需要空格。詳見第 5 條下方正例提示。
反例：if (空格 a == b 空格)
3. 【強制】if/for/while/switch/do 等保留字與括號之間都必須加空格。
4. 【強制】任何二目、三目運算符的左右兩邊都需要加一個空格。
說明：運算符包括賦值運算符=、邏輯運算符&&、加減乘除符號等。
5. 【強制】採用 4 個空格縮進，禁止使用 tab 字符。
6. 【強制】註釋的雙斜線與註釋內容之間有且僅有一個空格。
7. 【強制】在進行類型強制轉換時，右括號與強制轉換值之間不需要任何空格隔開。
8. 【強制】單行字符數限制不超過 120 個，超出需要換行，換行時遵循如下原則：
1）第二行相對第一行縮進 4 個空格，從第三行開始，不再繼續縮進，參考示例。
2）運算符與下文一起換行。
3）方法調用的點符號與下文一起換行。
4）方法調用中的多個參數需要換行時，在逗號後進行。
5）在括號前不要換行。
9. 【強制】方法參數在定義和傳入時，多個參數逗號後邊必須加空格。
10. 【推薦】不同邏輯、不同語義、不同業務的代碼之間插入一個空行分隔開來以提升可讀性。
（四）OOP規約
1. 【強制】所有的覆寫方法，必須加@ Override 註解。
2.【強制】避免使用Object
3. 【強制】不能使用過時的類或方法。如果方法已過時，去搜對應的更新後的方法。
4. 【強制】 Object 的 equals 方法容易拋空指針異常，應使用常量或確定有值的對象來調用equals ，例如應使用 "".equals(string)
5. 【強制】定義數據對象 DO （entity）類時，屬性類型要與數據庫字段類型相匹配
6. 關於基本數據類型與包裝數據類型的使用標準如下：
1） 【強制】所有的 POJO 類（定義對象的類）屬性必須使用包裝數據類型。
2） 【強制】RPC 方法的返回值和參數必須使用包裝數據類型。
3） 【推薦】所有的局部變量使用基本數據類型。
7. 【強制】定義 DO/DTO/VO 等 POJO 類時，不要設定任何默認值
8. 【強制】構造方法裏面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
9. 【強制】POJO 類必須寫 toString 方法。使用IDE自動生成，如果繼承了另一個 POJO 類，在前面加 super.toString。
10.【強制】禁止在 POJO 類中，同時存在對應屬性 xxx 的 isXxx()和 getXxx()方法。
11. 【推薦】 類內方法定義的順序依次是：公有方法或保護方法 > 私有方法 > getter / setter方法。
12.【強制】循環體內，字符串的連接方式，使用 StringBuilder 的 append 方法進行擴展。
集合處理，併發處理
（五）控制語句
1. 【強制】在 if / else / for / while / do 語句中必須使用大括號。
說明：即使只有一行代碼，避免採用單行的編碼方式：if (condition) statements;
2. 【強制】表達異常的分支時，少用 if-else 方式 ，這種方式可以改寫成：
if (condition) {
...
return obj;
}
// 接着寫 else 的業務邏輯代碼;
說明：如果非使用 if()...else if()...else...方式表達邏輯，避免後續代碼維護困難，【強制】請勿超過 3 層。
正例：超過 3 層的 if-else 的邏輯判斷代碼可以使用衛語句、策略模式、狀態模式等來實現，其中衛語句即代碼邏輯先考慮失敗、異常、中斷、退 出等直接返回的情況，以方法多個出口的方式，解決代碼中判斷分支嵌套的問題，這是逆向思維的體現。
衛語句，策略模式，狀態模式
3. 【強制】除常用方法（如 getXxx/isXxx ）等外，不要在條件判斷中執行其它複雜的語句，將複雜邏輯判斷的結果賦值給有意義的布爾變量名。
（六）註釋規約
1. 【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範，使用/**內容*/格式
2. 【強制】所有的抽象方法 （ 包括接口中的方法 ） 必須要用 Javadoc 註釋、除了返回值、參數、異常說明外，還必須指出該方法實現什麼功能。
3. 【強制】所有的類都必須添加創建者和創建日期。
4. 【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋使用/* */註釋，注意與代碼對齊。
二、異常日誌
（一）異常處理
1. 【強制】注意進行預檢查，即判斷是否爲null以及越界等。Java 類庫中定義的可以通過預檢查方式規避的 RuntimeException 異常不應該通過 catch 的方式來處理，比如：NullPointerException，IndexOutOfBoundsException 等等。
2. 【強制】異常不要用來做流程控制，條件控制
3. 【強制】避免出現重複的代碼 （Don ' t Repeat Yourself） ，即 DRY 原則。
說明：隨意複製和粘貼代碼，必然會導致代碼的重複，在以後需要修改時，需要修改所有的副本，容易遺漏。必要時抽取共性方法，或者抽象公共 類，甚至是組件化。
正例：一個類中有多個 public 方法，都需要進行數行相同的參數校驗操作，這個時候請抽取：private boolean checkParam(DTO dto) {...}
4. 【強制】遠程調用返回對象時，一律要求進行空指針判斷，防止 NPE。（JDK8中optional）
3、單元測試
4、安全規約
五、數據庫
8. 【強制】數據訂正（特別是刪除、修改記錄操作）時，要先 select ，避免出現誤刪除，確認無誤才能執行更新語句。
(四) ORM 映射
1. 【強制】在表查詢中，一律不要使用 * 作爲查詢的字段列表，需要哪些字段必須明確寫明。
2. 【強制】POJO 類的布爾屬性不能加 is，而數據庫字段必須加 is_，要求在 resultMap 中進行字段與屬性之間的映射
3. 【推薦】不要用 resultType當返回參數，即使所有類屬性名與數據庫字段一一對應，也需要定義；反過來，每一個表也必然有一個 POJO 類與 之對應。說明：配置映射關係，使字段與 DO 類解耦，方便維護。
4. 【推薦】sql. xml 配置參數使用：#{}，# param # 不要使用${} 此種方式容易出現 SQL 注入。
6、工程結構
7、設計規約