一、控制語句
1、【強制】在一個switch塊內，每個case要麼通過break/return等來終止，要麼註釋說明程序將繼續執行到哪一個case爲止；在一個switch塊內，都必須包含一個default語句並且放在最後，即使它什麼代碼也沒有。
2、【強制】在if /else /for /while /do 語句中必須使用大括號。即使只有一行代碼，避免採用單行的編碼方式：if (condition) statements;
3、【推薦】表達異常的分支時，少用if-else方式，這種方式可以改寫成：
if (condition) {
...
return obj;
}
// 接着寫else的業務邏輯代碼;
說明：如果非得使用if()...else if()...else...方式表達邏輯，【強制】避免後續代碼維護困難，請勿超過3層。
正例：超過3層的 if-else 的邏輯判斷代碼可以使用衛語句、策略模式、狀態模式等來實現，其中衛語句示例如下：
public void today() {
if (isBusy()) {
System.out.println(“change time.”);
return;
}
if (isFree()) {
System.out.println(“go to travel.”);
return;
}
System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);
return;
}
4、【推薦】除常用方法（如getXxx/isXxx）等外，不要在條件判斷中執行其它複雜的語句，將複雜邏輯判斷的結果賦值給一個有意義的布爾變量名，以提高可讀性。 說明：很多if語句內的邏輯相當複雜，閱讀者需要分析條件表達式的最終結果，才能明確什麼樣的條件執行什麼樣的語句，那麼，如果閱讀者分析邏輯表達式錯誤呢？ 正例：
// 僞代碼如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
反例： if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}
5、【推薦】循環體中的語句要考量性能，以下操作儘量移至循環體外處理，如定義對象、變量、獲取數據庫連接，進行不必要的try-catch操作（這個try-catch是否可以移至循環體外）。
二、註釋制約
1、【強制】類、類屬性、類方法的註釋必須使用Javadoc規範，使用/**內容*/格式，不得使用// xxx方式。
2、【強制】所有的類都必須添加創建者和創建日期
3、【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋使用/* */註釋，注意與代碼對齊。
4、【推薦】與其“半吊子”英文來註釋，不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文即可。
反例：“TCP連接超時”解釋成“傳輸控制協議連接超時”，理解反而費腦筋。
三、其他
1、【強制】注意 Math.random() 這個方法返回是double類型，注意取值的範圍 0≤x<1（能夠取到零值，注意除零異常），如果想獲取整數類型的隨機數，不要將x放大10的若干倍然後取整，直接使用Random對象的nextInt或者nextLong方法。
2、【強制】獲取當前毫秒數System.currentTimeMillis();而不是new Date().getTime(); 說明：如果想獲取更加精確的納秒級時間值，使用System.nanoTime()的方式。
在JDK8中，針對統計時間等場景，推薦使用Instant類。
3、【推薦】及時清理不再使用的代碼段或配置信息。
說明：對於垃圾代碼或過時配置，堅決清理乾淨，避免程序過度臃腫，代碼冗餘。
正例：對於暫時被註釋掉，後續可能恢復使用的代碼片斷，在註釋代碼上方，統一規定使用三個斜槓(///)來說明註釋掉代碼的理由。
4、【強制】對大段代碼進行try-catch，這是不負責任的表現。catch時請分清穩定代碼和非穩定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的catch儘可能進行區分異常類型，再做對應的異常處理。
5、【強制】有try塊放到了事務代碼中，catch異常後，如果需要回滾事務，一定要注意手動回滾事務。
6、【強制】finally塊必須對資源對象、流對象進行關閉，有異常也要做try-catch。 說明：如果JDK7及以上，可以使用try-with-resources方式。
7、【強制】不能在finally塊中使用return，finally塊中的return返回後方法結束執行，不會再執行try塊中的return語句。
8、【推薦】方法的返回值可以爲null，不強制返回空集合，或者空對象等，必須添加註釋充分說明什麼情況下會返回null值。調用方需要進行null判斷防止NPE問題。 說明：本手冊明確防止NPE是調用者的責任。即使被調用方法返回空集合或者空對象，對調用者來說，也並非高枕無憂，必須考慮到遠程調用失敗、序列化失敗、運行時異常等場景返回null的情況。
9、使用JDK8的Optional類來防止NPE問題
10、【參考】避免出現重複的代碼（Don’t Repeat Yourself），即DRY原則。 說明：隨意複製和粘貼代碼，必然會導致代碼的重複，在以後需要修改時，需要修改所有的副本，容易遺漏。必要時抽取共性方法，或者抽象公共類，甚至是組件化。正例：一個類中有多個public方法，都需要進行數行相同的參數校驗操作，這個時候請抽取：
private boolean checkParam(DTO dto) {...}
四、日誌規約
1、private static final Logger logger = LoggerFactory.getLogger(Abc.class);
2、【強制】對trace/ debug/ info級別的日誌輸出，必須使用條件輸出形式或者使用佔位符的方式。
說明：logger.debug("Processing trade with id: " + id + " and symbol: " + symbol); 如果日誌級別是warn，上述日誌不會打印，但是會執行字符串拼接操作，如果symbol是對象，會執行toString()方法，浪費了系統資源，執行了上述操作，最終日誌卻沒有打印。
正例：（條件）
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}
正例：（佔位符）
logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
3、【強制】避免重複打印日誌，浪費磁盤空間，務必在log4j.xml中設置additivity=false。 正例：<logger name="com.taobao.dubbo.config" additivity="false">
4、【推薦】謹慎地記錄日誌。生產環境禁止輸出debug日誌；有選擇地輸出info日誌；如果使用warn來記錄剛上線時的業務行爲信息，一定要注意日誌輸出量的問題，避免把服務器磁盤撐爆，並記得及時刪除這些觀察日誌。 說明：大量地輸出無效日誌，不利於系統性能提升，也不利於快速定位錯誤點。記錄日誌時請思考：這些日誌真的有人看嗎？看到這條日誌你能做什麼？能不能給問題排查帶來好處？
五、單元測試
1、【強制】好的單元測試必須遵守AIR原則。 說明：單元測試在線上運行時，感覺像空氣（AIR）一樣並不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。
A：Automatic （自動化）
I： Independent （獨立性）
R：Repeatable （可重複）
2、單元測試中不準使用System.out來進行人肉驗證，必須使用assert來驗證。
3、【強制】保持單元測試的獨立性。爲了保證單元測試穩定可靠且便於維護，單元測試用例之間決不能互相調用，也不能依賴執行的先後次序。
4、【強制】對於單元測試，要保證測試粒度足夠小，有助於精確定位問題。單測粒度至多是類級別，一般是方法級別。 說明：只有測試粒度小才能在出錯時儘快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯，那是集成測試的領域。
5、【強制】核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。 說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。
6、【推薦】編寫單元測試代碼遵守BCDE原則，以保證被測試模塊的交付質量。
B：Border，邊界值測試，包括循環、特殊取時間點數據順序等。
C：Correct，正確的輸入，並得到預期結果。
D：Design，與設計文檔相結合，來編寫單元測試
E：error，強制錯誤信息輸入（如：非法數據、異常流程業務允許等），並得 ，強制錯誤信息輸入（如：非法數據、異常流程業務允許等），並得預期的結果
