前言
作者：Guide哥來源：JavaGuide|2020-06-09 14:30
編程過程中，有太多太多讓我們頭疼的事情了，比如命名、維護其他人的代碼、寫測試、與其他人溝通交流等等。就連世界級軟件大師 Martin Fowler 大神都說過 CS 領域有兩大最難的事情，一是緩存失效，一是程序命名(@https://martinfowler.com/bliki/TwoHardThings.html)。
今天 Guide 就單獨拎出 “命名” 來聊聊，據說之前在 Quora 網站，由接近 5000 名程序員票選出來的最難的事情就是“命名”。
爲什麼需要重視命名?
好的命名即是註釋，別人一看到你的命名就知道你的變量、方法或者類是做什麼的! 好的命名對於其他人(包括你自己)理解你的代碼有着很大的幫助!
簡單舉個例子說明一下命名的重要性。
《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 service int count;
4.避免命名過長(50 個字符以內最好)，過長的命名難以閱讀並且醜陋。
5.不要使用拼音，更不要使用中文。 注意：像 alibaba 、wuhan、taobao 這種國際通用名詞可以當做英文來看待。
正例：discount
反例：dazhe
Codelf:變量命名神器?
這是一個由國人開發的網站，網上有很多人稱其爲變量命名神器， Guide 在實際使用了幾天之後感覺沒那麼好用。小夥伴們可以自行體驗一下，然後再給出自己的判斷。
Codelf 提供了在線網站版本，網址：https://unbug.github.io/codelf/，具體使用情況如下：
我選擇了 Java 編程語言，然後搜索了“序列化”這個關鍵詞，然後它就返回了很多關於序列化的命名。
總結
Guide 製作了一個涵蓋上面所有重要內容的思維導圖，便於小夥伴們日後查閱。
