你真的會(huì)給變量命名嗎？

作者： JavaEdge 2021-10-15 10:27:42

開(kāi)發(fā) 前端

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

[[429099]]

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

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

萬(wàn)金油命名法

什么叫精準(zhǔn)?

看段代碼：

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

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

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

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

將章節(jié)的翻譯狀態(tài)改成翻譯完畢
修改章節(jié)內(nèi)容

是不是也能叫處理章節(jié)呢?

所以，這的確是個(gè)過(guò)于寬泛的方法名，沒(méi)有大錯(cuò)，但不精確!

乍一看，這名字有含義，但實(shí)際卻不能有效反映這段代碼的具體含義。

若做的是個(gè)信息處理系統(tǒng)，你根本無(wú)法判斷，這是個(gè)博客平臺(tái)還是個(gè)圖書管理系統(tǒng)呢?

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

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

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

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

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

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

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

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

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

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

再看一段代碼：

這!也能有問(wèn)題?我天天看到還寫這種代碼啊。

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

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

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

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

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

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

追根究底，使用技術(shù)名詞，一般因?yàn)樗鄙賹?duì)應(yīng)模型。

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

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

但其實(shí)緩存這個(gè)概念也是個(gè)技術(shù)專業(yè)術(shù)語(yǔ)，也不應(yīng)出現(xiàn)在業(yè)務(wù)代碼中。

做得好的是 Spring，使用 Spring 時(shí)，若需要緩存，一般是加個(gè)注解：

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

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

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

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

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