有讀者看到標(biāo)題就開始敲鍵盤了，這還需要寫個(gè)文章來水？命名不就是不能用 abc、123 這種，名字要有意義嘛，這有啥好講的？

但現(xiàn)實(shí)中，雖然懂得名字要有意義，很多程序員依然無法逃離命名沼澤。

萬金油命名法

看段代碼：

看上去不是挺正常嗎？有何不可？

那我問你，這段代碼在干嘛？你就得全神貫注去閱讀代碼細(xì)節(jié)了。已閱后，你說這段代碼不就是把一個(gè)章節(jié)的翻譯狀態(tài)改成翻譯中。

為何你得閱完這段代碼細(xì)節(jié)，才知道該方法在干嘛？

問題就在方法名 - processChapter，該方法是在處理章節(jié)沒錯(cuò)，但這名太寬泛。如果說“將章節(jié)的翻譯狀態(tài)改成翻譯中”就叫處理章節(jié)，那么請問：

• 將章節(jié)的翻譯狀態(tài)改成翻譯完畢

• 修改章節(jié)內(nèi)容

是不是也能叫處理章節(jié)呢？
所以，這的確是個(gè)過于寬泛的方法名，沒有大錯(cuò)，但不精確！

乍一看，這名字有含義，但實(shí)際卻不能有效反映這段代碼的具體含義。
若做的是個(gè)信息處理系統(tǒng)，你根本無法判斷，這是個(gè)博客平臺(tái)還是個(gè)圖書管理系統(tǒng)呢？

從溝通角度看，這就不是一個(gè)有效信息表達(dá)。想理解它，需要消耗大量時(shí)間精力。

命名過于寬泛，不能精確描述，這是很多代碼命名現(xiàn)狀，也是讓祖?zhèn)鞔a難以理解的根因。

回想這些命名：data、info、flag、process、handle、build、maintain、manage、modify......

這些都屬于 過于寬泛的命名，當(dāng)這些名字出現(xiàn)在你的代碼，可以肯定作者當(dāng)時(shí)也沒想好用啥名字，就開始隨便起個(gè)萬金油名字繼續(xù)coding了。

扯半天，那它不能叫處理章節(jié)，那該叫啥？

• 命名要能精確描述該方法在做什么

  這段代碼就是“將章節(jié)改為翻譯中”。那是不是該叫 changeChapterToTranlsating？相比處理章節(jié)，這個(gè)名字已經(jīng)算進(jìn)步了，但也不算是個(gè)好名字，因?yàn)樗嗟氖窃诿枋鲞@段代碼在做的細(xì)節(jié)。而封裝一段代碼成方法，就是因?yàn)槲覀儾幌胫肋^多細(xì)節(jié)。如果把細(xì)節(jié)平鋪開來，那就和直接讀代碼細(xì)節(jié)沒啥區(qū)別了。

• 好名字應(yīng)該描述意圖，而非細(xì)節(jié)

  這段代碼為何要將翻譯狀態(tài)修改成翻譯中呢？一定是有所圖的。把翻譯狀態(tài)改成翻譯中，是因?yàn)槲覀冊谶@里開啟了一個(gè)翻譯的過程。所以，這個(gè)方法應(yīng)該叫?startTranslation

技術(shù)術(shù)語命名法

再看一段代碼：

這！也能有問題？我天天看到還寫這種代碼啊。

是的，我知道你們都在寫這種風(fēng)格代碼，這就是另一個(gè)經(jīng)典問題：技術(shù)術(shù)語命名法。

之所以叫 bookList，在于其聲明類型是 List。這種命名幾乎隨處可見，如 xxMap、xxSet。

這也是種不費(fèi)腦命名法，但這種命名卻會(huì)帶來很多問題，因?yàn)槭腔诩夹g(shù)實(shí)現(xiàn)細(xì)節(jié)的命名方式。

我們都知道面向接口編程原則，就是不要面向?qū)崿F(xiàn)編程，因?yàn)?strong>接口是穩(wěn)定的，而實(shí)現(xiàn)易變不穩(wěn)定。大多數(shù)人只覺得該原則是針對類型的，但命名方面，也同樣應(yīng)該遵循。比如，我發(fā)現(xiàn)現(xiàn)在需要的是個(gè)不重復(fù)作品集合，即我得把這個(gè)變量的類型從 List 改成 Set。變量類型相信你一定會(huì)改，但變量名你會(huì)改嗎？還真不一定，一旦忘了，就會(huì)出現(xiàn)：一個(gè) bookList 變量，居然是Set類型！

那怎么命名呢？得有個(gè)更能表達(dá)意圖的名字，這段代碼表達(dá)的就是拿到一堆書，所以可以叫?books。

這名字更簡單，也很表達(dá)意圖了。

追根究底，使用技術(shù)名詞，一般因?yàn)?/span>它缺少對應(yīng)模型。

比如，在業(yè)務(wù)代碼里若直接出現(xiàn) Redis：

通常來說，這里真正需要的是個(gè)緩存。Redis 只是緩存模型的一個(gè)具體實(shí)現(xiàn)：

但其實(shí)緩存這個(gè)概念也是個(gè)技術(shù)專業(yè)術(shù)語，也不應(yīng)出現(xiàn)在業(yè)務(wù)代碼中。
做得好的是 Spring，使用 Spring 時(shí)，若需要緩存，一般是加個(gè)注解：

很多人愛用技術(shù)名詞去命名，大多因?yàn)椋?/span>

• 熟悉的語言

• 寫代碼，很多都是參考別人代碼，優(yōu)秀代碼都是一些開源技術(shù)項(xiàng)目。那在一個(gè)技術(shù)類項(xiàng)目中，這些技術(shù)術(shù)語其實(shí)也就是它的業(yè)務(wù)語言。但對于我們的業(yè)務(wù)類項(xiàng)目，就不能生搬硬套了

若該部分確實(shí)就是處理一些技術(shù)，使用技術(shù)術(shù)語無可厚非，但若是在處理業(yè)務(wù)，就要盡可能規(guī)避技術(shù)術(shù)語。

像xxMap這種命名，表示映射關(guān)系，如：書id與書的映射關(guān)系，難道也不能命名為bookIdMap？

Map 表示的是個(gè)數(shù)據(jù)結(jié)構(gòu)，而映射關(guān)系推薦寫成 Mapping。

高級點(diǎn)的壞味道

前面的壞味道其實(shí)本質(zhì)都是同一問題：對業(yè)務(wù)理解不到位。

編寫可維護(hù)的代碼要使用業(yè)務(wù)語言。那如何知道自己的命名是否用的是業(yè)務(wù)語言呢？
把這個(gè)詞講給PM聽，看他懂是啥不。

團(tuán)隊(duì)里若每個(gè)人都根據(jù)自己理解命名，就可能出現(xiàn)百家爭鳴的命名，所以，一個(gè)良好的團(tuán)隊(duì)實(shí)踐是建立團(tuán)隊(duì)的業(yè)務(wù)詞匯表，統(tǒng)一業(yè)務(wù)命名。

當(dāng)團(tuán)隊(duì)對業(yè)務(wù)有了一致的理解后，興許還能發(fā)現(xiàn)更高級的壞味道：

看方法名，應(yīng)該是確認(rèn)章節(jié)內(nèi)容審核通過。

但我有一問，chapterId 是審核章節(jié)的 ID，這沒問題，但 userId 是啥？了解背景后，才知道這里要 userId，是因?yàn)樾枰涗泴徍巳诵畔ⅰ?/span>

通過業(yè)務(wù)的分析，就發(fā)現(xiàn)，這個(gè) userId 不是個(gè)好名字，因?yàn)樗€需要更多解釋，更好的命名是 reviewerUserId，因?yàn)檫@用戶在當(dāng)前場景下就是審核人（Reviewer）角色。

這也是一種萬金油命名法，但它不是那種一眼就能看出的壞味道，而是需要在業(yè)務(wù)層進(jìn)行討論，所以，算個(gè)高級壞味道。

往期推薦