現代軟件架構的復雜性需要協同開發完成，如何高效地協同呢？
答案是：制定一整套統一的規范。
無規矩不成方圓，無規范難以協同，比如，制訂交通法規表面上是要限制行車權，實際上是保障公眾的人身安全，試想如果沒有限速，沒有紅綠燈，誰還敢上路行駛？
本文將從Java代碼的命名規范這一維度，來探討一下，如何寫出健壯的、可讀性強的代碼，提高項目的可維護性。最重要的是提高我們的編程幸福感。
1.包名統一使用小寫，點分隔符之間有且僅有一個自然語義的英語單詞。包名統一使用單數形式，但是類名如果有復數含義，類名可以使用復數形式。
正例：應用工具包名為com.java.util、類名為StringUtils
2.類名、接口名使用UpperCamelCase風格，必須遵從駝峰形式，但以下情形例外：DO/BO/DTO/VO/AO/PO/UID等。
正例：UserLoginCheckService/UserDO
反例：userlogincheckservice/UserDo
3.方法名、參數名、成員變量、局部變量都統一使用lowerCamelCase風格，必須遵從駝峰形式。
正例：userServiceImpl
反例：userserviceimpl
4.常量命名全部大寫，單詞間用下划線隔開，力求語義表達完整清楚，不要嫌名字長。
正例：MAX_BOOK_COUNT/CACHE_EXPIRED_TIME
反例：MAX_COUNT/EXPIRED_TIME
5.為了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡量完整的單詞組合來表達其意，即要做到“見名知意”。
正例：在 JDK 中，表達原子更新的類名為：AtomicReferenceFieldUpdater
反例：String a = "李四"; // 天啦嚕，鬼知道你這個a是啥意思啊
6.定義數組時，類型與中括號緊挨相連
正例：
int[] array = new int[10];
int array[] = new int[10]; // 不建議這樣寫
7.抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類命名以它要測試的類的名稱開始，以 Test 結尾。
正例：AbstractService/CommonException/DemoTest
8.杜絕完全不規范的縮寫，避免望文不知義。
反例：AbstractClass“縮寫”命名成 AbsClass；condition“縮寫” 命名成 condi，此類隨意縮寫嚴重降低了代碼的可閱讀性。
9.如果模塊、 接口、類、方法使用了設計模式，在命名時需體現出具體模式
說明：將設計模式體現在名字中，有利於閱讀者快速理解架構設計理念。
正例：public class OrderFactory;
public class LoginProxy;
public class ResourceObserver;
10.對於 Service 和 DAO 類，基於 SOA 的理念，暴露出來的服務一定是接口，內部的實現類用Impl 的后綴與接口區別。
正例：CacheServiceImpl實現CacheService接口
11.如果是形容能力的接口名稱，取對應的形容詞為接口名（通常是–able 的形容詞）。
正例：JDK中的Comparable接口
12.在long或者Long賦值時，數值后使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混淆，造成誤解。
說明：Long a = 2l；寫的是數字的 21，還是 Long 型的 2 ？？
13.不允許任何魔法值（即未經預先定義的常量）直接出現在代碼中
正例：
public static final ORDER_REDIS_KEY_PREFIX = "orderId_";
String orderRedisKey = ORDER_REDIS_KEY_PREFIX + orderId;
反例：
String redisKey = "orderId_" + orderId;
14.枚舉類名帶上Enum后綴，枚舉成員名稱需要全大寫，單詞間用下划線隔開。
正例：枚舉名字為ProcessStatusEnum的成員名稱：SUCCESS / UNKNOWN_REASON
