現代軟件架構的復雜性需要協同開發完成，如何高效地協同呢？

答案是：制定一整套統一的規范。

無規矩不成方圓，無規范難以協同，比如，制訂交通法規表面上是要限制行車權，實際上是保障公眾的人身安全，試想如果沒有限速，沒有紅綠燈，誰還敢上路行駛？

本文將從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

總結

以上是生活随笔為你收集整理的java类的命名规范_浅谈Java中的命名规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。