為什麼需要重視命名？

好的命名即是註釋，別人一看到你的命名就知道你的變數、方法或者類是做什麼的！好的命名對於其他人（包括你自己）理解你的程式碼有著很大的幫助！

簡單舉個例子說明一下命名的重要性。

《Clean Code》這本書明確指出：

好的程式碼本身就是註釋，我們要儘量規範和美化自己的程式碼來減少不必要的註釋。

若程式語言足夠有表達力，就不需要註釋，儘量通過程式碼來闡述。

舉個例子：

去掉下面複雜的註釋，只需要建立一個與註釋所言同一事物的函式即可

// check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

應替換為

if (employee.isEligibleForFullBenefits())

常見命名規則以及適用場景

這裡只介紹 3 種最常見的命名規範。

駝峰命名法（CamelCase）

駝峰命名法應該我們最常見的一個，這種命名方式使用大小寫混合的格式來區別各個單詞，並且單詞之間不使用空格隔開或者連線字元連線的命名方式

大駝峰命名法（CamelCase）

類名需要使用大駝峰命名法（UpperCamelCase）

正例：

ServiceDiscovery、ServiceInstance、LruCacheFactory

反例：

serviceDiscovery、Serviceinstance、LRUCacheFactory

小駝峰命名法（lowerCamelCase）

方法名、引數名、成員變數、區域性變數需要使用小駝峰命名法（lowerCamelCase）。

正例：

getUserInfo()、createCustomThreadPool()、setNameFormat(String nameFormat)
Uservice userService;

反例：

GetUserInfo()、CreateCustomThreadPool()、setNameFormat(String NameFormat)
Uservice user_service

蛇形命名法（snake_case）

測試方法名、常量、列舉名稱需要使用蛇形命名法（snake_case）

在蛇形命名法中，各個單詞之間通過下劃線“_”連線，比如should_get_200_status_code_when_request_is_valid、CLIENT_CONNECT_SERVER_FAILURE。

蛇形命名法的優勢是命名所需要的單詞比較多的時候，比如我把上面的命名通過小駝峰命名法給大家看一下：“shouldGet200StatusCodoWhenRequestIsValid”。感覺如何？ 相比於使用蛇形命名法（snake_case）來說是不是不那麼易讀？**

正例：

@Test
void should_get_200_status_code_when_request_is_valid() {
  ......
}

反例：

@Test
void shouldGet200StatusCodoWhenRequestIsValid() {
  ......
}

串式命名法（kebab-case）

在串式命名法中，各個單詞之間通過下劃線“-”連線，比如dubbo-registry。

建議專案資料夾名稱使用串式命名法（kebab-case），比如 dubbo 專案的各個模組的命名是下面這樣的。

常見命名規範

Java 語言基本命名規範

1.類名需要使用大駝峰命名法（UpperCamelCase）風格。方法名、引數名、成員變數、區域性變數需要使用小駝峰命名法（lowerCamelCase）。

2.測試方法名、常量、列舉名稱需要使用蛇形命名法（snake_case），比如should_get_200_status_code_when_request_is_valid、CLIENT_CONNECT_SERVER_FAILURE。並且，測試方法名稱要求全部小寫，常量以及列舉名稱需要全部大寫。

3.專案資料夾名稱使用串式命名法（kebab-case），比如dubbo-registry。

4.包名統一使用小寫，儘量使用單個名詞作為包名，各個單詞通過 "." 分隔符連線，並且各個單詞必須為單數。

正例：org.apache.dubbo.common.threadlocal

反例：org.apache.dubbo.common.threadLocal

5.抽象類命名使用 Abstract 開頭。

//為遠端傳輸部分抽象出來的一個抽象類（出處：Dubbo原始碼）
public abstract class AbstractClient extends AbstractEndpoint implements Client {

}

6.異常類命名使用 Exception 結尾。

//自定義的 NoSuchMethodException（出處：Dubbo原始碼）
public class NoSuchMethodException extends RuntimeException {
    private static final long serialVersionUID = -2725364246023268766L;

    public NoSuchMethodException() {
        super();
    }

    public NoSuchMethodException(String msg) {
        super(msg);
    }
}

7.測試類命名以它要測試的類的名稱開始，以 Test 結尾。

//為 AnnotationUtils 類寫的測試類（出處：Dubbo原始碼）
public class AnnotationUtilsTest {
  ......
}

POJO 類中布林型別的變數，都不要加 is 字首，否則部分框架解析會引起序列化錯誤。

如果模組、介面、類、方法使用了設計模式，在命名時需體現出具體模式。

命名易讀性規範

1.為了能讓命名更加易懂和易讀，儘量不要縮寫/簡寫單詞，除非這些單詞已經被公認可以被這樣縮寫/簡寫。比如CustomThreadFactory不可以被寫成 ~~CustomTF。

2.命名不像函式一樣要儘量追求短，可讀性強的名字優先於簡短的名字，雖然可讀性強的名字會比較長一點。這個對應我們上面說的第 1 點。

3.避免無意義的命名，你起的每一個名字都要能表明意思。

正例：UserService userService;int userCount;

反例:UserService serviceint count

4.避免命名過長（50 個字元以內最好），過長的命名難以閱讀並且醜陋。

5.不要使用拼音，更不要使用中文。注意：像 alibaba 、wuhan、taobao 這種國際通用名詞可以當做英文來看待。

正例：discount

反例：dazhe

Codelf:變數命名神器?

這是一個由國人開發的網站，網上有很多人稱其為變數命名神器， Guide 在實際使用了幾天之後感覺沒那麼好用。小夥伴們可以自行體驗一下，然後再給出自己的判斷。

Codelf 提供了線上網站版本，網址：https://unbug.github.io/codelf/，具體使用情況如下：

我選擇了 Java 程式語言，然後搜尋了“序列化”這個關鍵詞，然後它就返回了很多關於序列化的命名。

並且，Codelf 還提供了 VS code 外掛，看這個評價，看來大家還是很喜歡這款命名工具的。

總結

如下圖所示，涵蓋上面所有重要內容的思維導圖，便於小夥伴們日後查閱。

其他推薦閱讀

1. 《阿里巴巴 Java 開發手冊》
2. 《Clean Code》
3. Google Java 程式碼指南：https://google.github.io/styleguide/javaguide.html#s5.1-identifier-name
4. 告別編碼5分鐘，命名2小時！史上最全的Java命名規範參考：https://www.cnblogs.com/liqiangchn/p/12000361.html

作者：Snailclimb
連結：Java 命名之道
來源：github