排版
原則 團隊應遵守一致的排版風格
規則1 在不同的概念之間，增加空行。如import與包名，import與類名，方法與方法，類與類，變量聲明與變量聲明。
規則2 將邏輯緊密相關的代碼放在一起。
規則3 控制一行的寬度，不要超過120個字符。換行應在低優先級運算符處換行。
規則4 控制一行的寬度，在不同的概念之間（關鍵字、變量·、操作符等·）增加空格，以便區分概念。
規則5 控制採用縮進來區分不同層次的概念（不用tab，用4空格）。
建議1 將局部變量的作用域最小化。
建議2 if,for,do,while,case,switch,default等語句自佔一行，且if,for,do,while語句的執行語句無論多少都要加括號。
建議3 控制好文件長度，最好不要超過500行。
註釋
原則 儘量使用代碼來解釋自己
規則1 註釋應解釋代碼的意圖，而不是描述代碼怎麼做的。
規則2 保證註釋與代碼一致，避免產生誤導。
規則3 註釋應與其描述代碼位置相鄰，放在所註釋代碼上方或者右方，並與代碼採用同樣的縮進。
建議1 不要用註釋保留廢棄代碼。
建議2 不要用註釋記錄修改日誌。
命名
原則 團隊爲包、類、方法、變量取一個好名字，使代碼易於理解
規則1 禁止使用魔鬼數字。
規則2 常量命名，由全大寫單詞組成，單詞間用下劃線分割，且使用static final修飾
規則3 變量、屬性命名，使用名詞，並採用首字母小寫的駝峯命名
規則4 方法的命名，用動詞和動賓結構，採用首字母小寫的駝峯命名
規則5 類和接口的命名，採用首字母大寫的駝峯命名法
規則6 包的命名，由一個或若干個單詞組成，所有的字母均爲小寫
變量和類型
原則 謹慎使用靜態成員變量
錯誤使用靜態變量可能有以下場景：
1、認爲靜態變量屬於某個實例，而實際是多個實例操作同一個變量，造成值與預期不一致
2、沒有注意靜態變量的初始化順序，讀取還未初始化的靜態變量值。
推薦在以下場景中，合理使用靜態變量：
1、類的所有實例必須共享同一個變量時，比如計數器。
2、工具類提供的常量，如配置文件中的參數“映射”到類的變量，基本第一次賦值後，數據不再被修改。
3、單例模式中應用
規則1 避免隨意進行類型強行轉換，應改善設計，或在轉換前用instanceof進行判斷。
規則2 需要精確計算時不要使用float和double，建議使用int,long,BigDecimal。
規則3 不能使用浮點數作爲循環變量，例，精度問題會導致（float） 20000000000 == 20000000020爲true
規則4 浮點型數據判斷相等不能直接使用 ==
一般採用如下：
float a=...;
float b=...;
if(Math.abs(a-b)<1E-6f)
{
}
規則5 避免同一個局部變量在前後表達不同的含義
規則6 不要在單個的表達式中對相同的變量賦值吵過一次。
方法
原則1 方法設計的第一原則是短小
原則2 方法設計應遵循單一職責原則（SRP），一個方法僅完成一個功能
原則3 方法設計應遵循單一抽象層次原則（SLAP）
原則4 方法設計應遵循命名與查詢職責分離原則（CQRS）
規則1 不要把方法的入參作爲工作變量/臨時變量，除非特別需要（如，方法外需要改變後的方法內引用變量）
規則2 使用類名調用靜態方法，而不要用實例或表達式來調用
建議1 應明確規定對接口方法參數的合法性由調用者負責還是由方法本身負責。
建議2 謹慎使用可變數量參數的方法
建議3 對接方法的參數不宜過多
包、類和接口
原則1 類和接口的設計應遵循面向對象SOLID設計原則
1、單一職責原則
說明：就一個類而言，應該僅有一個引起它變化的原因。如果能想到多於一個的動機去改變類，那麼這個類就具有多於一個的職責
異常
原則1 只針對真正異常的情況纔會使用exception機制
規則2 對可恢復的情況使用受檢異常（checked exception）對編程錯誤使用運行時異常（runtime exceptio）
規則3 不要忽略異常
規則4 方法註釋和文檔中要包含所拋出異常的說明
規則5 方法拋出的異常，應該與本身的抽象層次相對應
規則6 在finally塊中不要使用return、break或continue使finally塊非正常結束。
規則7 不要直接捕獲受檢異常的基類Exception
建議1 對第三方API拋出的大量各類異常進行封裝
建議2 一個方法不應該拋出太多類型的異常