你真的會給變量命名嗎？
有讀者看到標題就開始敲鍵盤了，這還需要寫個文章來水?命名不就是不能用 abc、123 這種，名字要有意義嘛，這有啥好講的?
但現實中，雖然懂得名字要有意義，很多程序員依然無法逃離命名沼澤。
萬金油命名法
什么叫精準?
看段代碼：
看上去不是挺正常嗎?有何不可?
那我問你，這段代碼在干嘛?你就得全神貫注去閱讀代碼細節了。已閱后，你說這段代碼不就是把一個章節的翻譯狀態改成翻譯中。
為何你得閱完這段代碼細節，才知道該方法在干嘛?
問題就在方法名 - processChapter，該方法是在處理章節沒錯，但這名太寬泛。如果說“將章節的翻譯狀態改成翻譯中”就叫處理章節，那么請問：
- 將章節的翻譯狀態改成翻譯完畢
- 修改章節內容
是不是也能叫處理章節呢?
所以，這的確是個過于寬泛的方法名，沒有大錯，但不精確!
乍一看，這名字有含義，但實際卻不能有效反映這段代碼的具體含義。
若做的是個信息處理系統，你根本無法判斷，這是個博客平臺還是個圖書管理系統呢?
從溝通角度看，這就不是一個有效信息表達。想理解它，需要消耗大量時間精力。
命名過于寬泛，不能精確描述，這是很多代碼命名現狀，也是讓祖傳代碼難以理解的根因。
回想這些命名：data、info、flag、process、handle、build、maintain、manage、modify......
這些都屬于 過于寬泛的命名，當這些名字出現在你的代碼，可以肯定作者當時也沒想好用啥名字，就開始隨便起個萬金油名字繼續coding了。
扯半天，那它不能叫處理章節，那該叫啥?
- 命名要能精確描述該方法在做什么
這段代碼就是“將章節改為翻譯中”。那是不是該叫 changeChapterToTranlsating?相比處理章節，這個名字已經算進步了，但也不算是個好名字，因為它更多的是在描述這段代碼在做的細節。而封裝一段代碼成方法，就是因為我們不想知道過多細節。如果把細節平鋪開來，那就和直接讀代碼細節沒啥區別了。
- 好名字應該描述意圖，而非細節
這段代碼為何要將翻譯狀態修改成翻譯中呢?一定是有所圖的。把翻譯狀態改成翻譯中，是因為我們在這里開啟了一個翻譯的過程。所以，這個方法應該叫 startTranslation
技術術語命名法
再看一段代碼：
這!也能有問題?我天天看到還寫這種代碼啊。
是的，我知道你們都在寫這種風格代碼，這就是另一個經典問題：技術術語命名法。
之所以叫 bookList，在于其聲明類型是 List。這種命名幾乎隨處可見，如 xxMap、xxSet。
這也是種不費腦命名法，但這種命名卻會帶來很多問題，因為是基于技術實現細節的命名方式。
我們都知道面向接口編程原則，就是不要面向實現編程，因為接口是穩定的，而實現易變不穩定。大多數人只覺得該原則是針對類型的，但命名方面，也同樣應該遵循。比如，我發現現在需要的是個不重復作品集合，即我得把這個變量的類型從 List 改成 Set。變量類型相信你一定會改，但變量名你會改嗎?還真不一定，一旦忘了，就會出現：一個 bookList 變量，居然是Set類型!
那怎么命名呢?得有個更能表達意圖的名字，這段代碼表達的就是拿到一堆書，所以可以叫 books。
這名字更簡單，也很表達意圖了。
追根究底，使用技術名詞，一般因為它缺少對應模型。
比如，在業務代碼里若直接出現 Redis：
通常來說，這里真正需要的是個緩存。Redis 只是緩存模型的一個具體實現：
但其實緩存這個概念也是個技術專業術語，也不應出現在業務代碼中。
做得好的是 Spring，使用 Spring 時，若需要緩存，一般是加個注解：
很多人愛用技術名詞去命名，大多因為：
- 熟悉的語言
- 寫代碼，很多都是參考別人代碼，優秀代碼都是一些開源技術項目。那在一個技術類項目中，這些技術術語其實也就是它的業務語言。但對于我們的業務類項目，就不能生搬硬套了
若該部分確實就是處理一些技術，使用技術術語無可厚非，但若是在處理業務，就要盡可能規避技術術語。
像xxMap這種命名，表示映射關系，如：書id與書的映射關系，難道也不能命名為bookIdMap?
Map 表示的是個數據結構，而映射關系推薦寫成 Mapping。
高級點的壞味道
前面的壞味道其實本質都是同一問題：對業務理解不到位。
編寫可維護的代碼要使用業務語言。那如何知道自己的命名是否用的是業務語言呢?
把這個詞講給PM聽，看他懂是啥不。
團隊里若每個人都根據自己理解命名，就可能出現百家爭鳴的命名，所以，一個良好的團隊實踐是建立團隊的業務詞匯表，統一業務命名。
當團隊對業務有了一致的理解后，興許還能發現更高級的壞味道：
看方法名，應該是確認章節內容審核通過。
但我有一問，chapterId 是審核章節的 ID，這沒問題，但 userId 是啥?了解背景后，才知道這里要 userId，是因為需要記錄審核人信息。
通過業務的分析，就發現，這個 userId 不是個好名字，因為它還需要更多解釋，更好的命名是 reviewerUserId，因為這用戶在當前場景下就是審核人(Reviewer)角色。
這也是一種萬金油命名法，但它不是那種一眼就能看出的壞味道，而是需要在業務層進行討論，所以，算個高級壞味道。
