[[120348]]

一個(gè)軟件***都會(huì)落實(shí)到代碼。而代碼，其背后的架構(gòu)設(shè)計(jì)或設(shè)計(jì)思想或模式固然重要，但我覺(jué)得更重要的東西則是良好的命名。混亂或錯(cuò)誤的命名不僅讓我 們對(duì)代碼難以理解，更糟糕的是，會(huì)誤導(dǎo)我們的思維，導(dǎo)致對(duì)代碼的理解完全錯(cuò)誤。相反，良好的命名，則可以讓我們的代碼非常容易讀懂，也能向讀者正確表達(dá)事 物以及邏輯的本質(zhì)，從而使得代碼的可維護(hù)性就大大增強(qiáng)，讀命名好的文章是非常流暢的，會(huì)有一種享受的感覺(jué)。

另外一點(diǎn)也許大家還沒(méi)感受到，那就是良好的命名，以及良好的命名習(xí)慣，由于我們總是對(duì)每個(gè)概念的名稱(chēng)要求非?？量蹋覀儠?huì)思考這個(gè)名稱(chēng)所表達(dá)的概念 是否正確，該名稱(chēng)是否正確表達(dá)了事物的本質(zhì)或正確反映了某個(gè)行為的邏輯。所以，這種對(duì)命名的良好思考習(xí)慣，可以反過(guò)來(lái)幫助我們糾正之前的一些錯(cuò)誤設(shè)計(jì)和代 碼實(shí)現(xiàn)；比如，你之前有一個(gè)地方可能命名不太準(zhǔn)確，然后你發(fā)現(xiàn)后面有另一個(gè)地方需要用這個(gè)名字，且更合理。所以你會(huì)發(fā)現(xiàn)這個(gè)名字對(duì)前面的地方就不適合了， 從而你會(huì)去思考前面的地方可能需要用其他的名字，或者你會(huì)發(fā)現(xiàn)前面的地方的設(shè)計(jì)根本就是有問(wèn)題的。這種就是名字可以促使你思考你的設(shè)計(jì)是否正確的例子。

代碼命名混亂或錯(cuò)誤的主要原因：

1. 沒(méi)理解事物的本質(zhì)；
2. 理解了事物的本質(zhì)，但不知道命名的重要性或者根本不屑于做好命名；
3. 理解了事物的本質(zhì)，也知道命名的重要性，但沒(méi)能力命名好事物；

養(yǎng)成良好的命名習(xí)慣的一些想法：

1. 對(duì)自己的嚴(yán)格自律，自己寫(xiě)代碼時(shí)要有一種希望把每個(gè)名稱(chēng)都命名好的強(qiáng)烈意識(shí)和嚴(yán)格的自律意識(shí)；
2. 要努力分析和思考當(dāng)前被你命名的事物或邏輯的本質(zhì)；這點(diǎn)非常關(guān)鍵，思考不深入，就會(huì)導(dǎo)致***對(duì)這個(gè)事物的命名錯(cuò)誤，因?yàn)槟氵€沒(méi)想清楚被你命名的事物是個(gè)什么東西；
3. 在有自律意識(shí)和一定的分析能力基礎(chǔ)之上，注意命名的方法技巧；要知道何時(shí)用動(dòng)詞，何時(shí)用名詞；以及形容詞放哪里，動(dòng)詞放哪里，名詞放哪里；也就是小學(xué)時(shí)的主謂賓要會(huì)用；
4. 你的任何一個(gè)屬性的名字都要和其實(shí)際所代表的含義一致；你的任何一個(gè)方法所做的事情都要和該方法的名字的含義一致；
5. 從代碼的命名可以看出寫(xiě)代碼的人編程時(shí)思路是否清晰，如果你對(duì)一個(gè)名字的命名不準(zhǔn)確，很可能體現(xiàn)出你還沒(méi)有理解這個(gè)名字背后的東西；
6. 要讓你的程序的每個(gè)相似的地方的命名風(fēng)格總是一致的。不要一會(huì)兒大寫(xiě)，一會(huì)兒小寫(xiě)；一會(huì)兒全稱(chēng)一會(huì)兒簡(jiǎn)寫(xiě)；一會(huì)兒Pascal命名法，一會(huì)兒camel命名法或匈牙利命名法；
7. 不要出現(xiàn)重復(fù)的命名；因?yàn)橥ǔＣQ(chēng)都有嵌套關(guān)系，比如類(lèi)在命名空間里，方法在類(lèi)里，所有如果一個(gè)概念在命名空間里表達(dá)了，那就不必再類(lèi)上再表達(dá)一次；
8. 對(duì)于屬性或類(lèi)名，應(yīng)該總是名詞在***面，名詞決定了這個(gè)屬性代表什么，前面的部分都是用于修飾這個(gè)名詞；比如，假如現(xiàn)在你有一個(gè)服務(wù)，然后又是一 個(gè)關(guān)于訂單的服務(wù)，那就可以命名為OrderService，這樣命名就是告訴我們這是一個(gè)服務(wù)，然后是一個(gè)訂單服務(wù)；再比如 CancelOrderCommand，看到這個(gè)我們就知道這是一個(gè)Command，即命令，然后是什么命令呢？就是一個(gè)取消訂單的命 令，CancelOrder表示取消訂單；
9. 對(duì)于方法，應(yīng)該總是動(dòng)詞開(kāi)頭，名詞結(jié)尾；比如Order.AddItem(orderItem);這個(gè)，表示訂單類(lèi)有一個(gè)添加訂單項(xiàng)的方法，Add是動(dòng)詞，表示添加，Item是名詞表示訂單項(xiàng)；
10. 在C#中，我們一般用camel以及Pascal命名法，而不是匈牙利命名法。我覺(jué)得主要是兩個(gè)原因：1）VS強(qiáng)大的智能感知提示的存在，我們沒(méi) 有必要突出變量的類(lèi)型了，但這個(gè)我覺(jué)得只是一個(gè)次要原因；2）真正的原因，我上面有提到，一個(gè)變量，名詞是放在***的，這個(gè)名詞決定了這個(gè)變量代表什么。 比如有個(gè)變量叫totalCount，我們一看就知道這是一個(gè)count，然后count一定是一個(gè)int或者long，所以就不需要在強(qiáng)調(diào)它的類(lèi)型了。 再比如，remotingRequest, httpRequest，這種，我們也一看就知道他們是請(qǐng)求，一個(gè)是remoting的請(qǐng)求，一個(gè)是http的請(qǐng)求。remoting,http是用來(lái)修 飾request的。request決定了這個(gè)變量是什么（同時(shí)就意味著我們知道了他的類(lèi)型了），然后remoting,http這種是進(jìn)一步說(shuō)明該 request的業(yè)務(wù)含義或當(dāng)前上下文。就像disabledButton，我們一看就知道這是一個(gè)button，然后是一個(gè)什么Button呢，就是一 個(gè)已禁用的button。所以，好的名稱(chēng)，本身就會(huì)讓我們很容易知道該名稱(chēng)是什么東西，它的類(lèi)型是什么，具有什么業(yè)務(wù)含義，所以沒(méi)有必要再加類(lèi)型縮寫(xiě)作為 前綴；
11. 多學(xué)習(xí)英文，多看國(guó)外優(yōu)秀開(kāi)源項(xiàng)目中的命名技巧，會(huì)對(duì)我們命名有很大幫助；

通過(guò)一些不太好的代碼命名來(lái)分析一些簡(jiǎn)單的命名問(wèn)題

以上代碼中，有很多問(wèn)題，我們來(lái)一一分析：

1. 方法的參數(shù)，***個(gè)字母，一會(huì)兒大寫(xiě)的P，一會(huì)兒小寫(xiě)的p，不一致；
2. 第二個(gè)參數(shù)后面出現(xiàn)多余的空格，不應(yīng)該；
3. _paramsTable這個(gè)參數(shù)為什么要出現(xiàn)下劃線(xiàn)，而其他參數(shù)沒(méi)有下劃線(xiàn)，不一致；
4. publishRequest屬于camel命名法，而iSignCounter, sStageIsOK這種屬于另一種命名法，這種命名c++中用的多，不一致；
5. foreach循環(huán)中，參數(shù)名叫instParam，但是后面的集合叫arrParams4SignActions，更對(duì)稱(chēng)一點(diǎn)的，應(yīng)該叫arrInstParam；
6. 方法的***兩行，出現(xiàn)多余的空格，導(dǎo)致代碼格式排版混亂；

從上面的代碼我們可以知道，僅僅是通過(guò)這些細(xì)節(jié)，就能發(fā)現(xiàn)很多問(wèn)題。我們寫(xiě)代碼時(shí)，只要多細(xì)心點(diǎn)，多注意點(diǎn)排版是否美觀(guān)一致、命名是否統(tǒng)一，那代碼寫(xiě)出來(lái)就會(huì)漂亮很多了。下面我們?cè)倏纯雌渌拇a：

1. 上面的代碼中，兩個(gè)參數(shù)的命名也不一致，projectid中，i是小寫(xiě)，但是publishId參數(shù)，i卻是大寫(xiě)，應(yīng)該都統(tǒng)一為大寫(xiě)；
2. ViewData中的key，一會(huì)兒是全部大寫(xiě)的UPDATE，一會(huì)兒是另一種命名，不一致；
3. 上面的兩個(gè)紅框標(biāo)出來(lái)的if，雖然都是只有一行代碼，但是一個(gè)有括號(hào)，一個(gè)沒(méi)有括號(hào)，不一致；且第二個(gè)if里出現(xiàn)了多余的空行，格式混亂；

1. 上面的代碼中，函數(shù)中，一會(huì)兒用IList，是一個(gè)接口，一會(huì)兒用Dictionary，非接口，不一致；應(yīng)該都用接口，或者都不用接口；
2. listOriginal和receiverList命名不一致，要么全部list開(kāi)頭，要么全部List結(jié)尾；
3. foreach循環(huán)中，變量的類(lèi)型叫TDMSOriginalRequirement，但是變量名卻叫originalItem，而集合名稱(chēng)又叫 listOriginal，應(yīng)該三者統(tǒng)一；比如foreach (Assembly assembly in assemblies)
4. +“…”這個(gè)地方?jīng)]有用空格，加號(hào)兩邊應(yīng)該要空格，這屬于格式混亂，不嚴(yán)謹(jǐn)；
5. createUser這個(gè)變量取的很不理想，create是動(dòng)詞，createUser合起來(lái)就是創(chuàng)建用戶(hù)的意思，而他這里要表達(dá)的意思是創(chuàng)建人的意思，所以應(yīng)該叫createdUser或者creator；
6. 為何originalItemFormat和originalItem的意思可以等價(jià)，不合理，如果等價(jià)，一開(kāi)始就要命名為originalItemFormat；而且format是一個(gè)東西，動(dòng)詞放在***，算個(gè)啥？

1. 上面這個(gè)類(lèi)的幾個(gè)私有字段中，有些帶命名空間，有些不帶，要么都不帶，要么都帶；一般命名空間都是在上面聲明，后續(xù)不需要出現(xiàn)；
2. ILog logger；這一句有兩個(gè)問(wèn)題：1）logger為何沒(méi)有下劃線(xiàn)，不統(tǒng)一；2）為何類(lèi)名叫ILog，而變量名叫l(wèi)ogger，要統(tǒng)一，要么類(lèi)名叫ILogger，要么變量名叫_log；

上面這兩個(gè)私有方法，一個(gè)是大寫(xiě)開(kāi)頭，一個(gè)是小寫(xiě)開(kāi)頭，不一致，混亂；應(yīng)該要一致；

總結(jié)

通過(guò)上面的一些例子，我們知道，在我們不經(jīng)意間，多寫(xiě)了一個(gè)空格或者一個(gè)空行，或者一個(gè)字母的大小寫(xiě)不一致了，都會(huì)導(dǎo)致命名的不一致；如果自己沒(méi)有 養(yǎng)成這種平時(shí)注重代碼命名各種一致性的習(xí)慣，那寫(xiě)出來(lái)的代碼很可能就是像上面那樣。我覺(jué)得是非常糟糕的。上面我舉的例子都只是簡(jiǎn)單的命名方面的，更深層次 的命名問(wèn)題，比如如何做到名稱(chēng)和其背后的實(shí)現(xiàn)內(nèi)容一致，這個(gè)是需要我們平時(shí)不斷修煉的。不是短時(shí)間內(nèi)就可以做到那個(gè)程度。

我覺(jué)得，要做好命名，歸根結(jié)底：

1）先要意識(shí)到命名的重要性；2）要端正態(tài)度，要認(rèn)真的寫(xiě)代碼；3）要努力推敲每個(gè)名稱(chēng)和其實(shí)際做的事情是否一致，也就是命名的準(zhǔn)確性；4）要時(shí)刻注意命名的各種一致性；

養(yǎng)成良好的命名習(xí)慣不是為了別人，不是為了公司，而是為了提高自己的編程修養(yǎng)，提高自己認(rèn)識(shí)事物的能力。