變量命名那點小事

代碼好似程序員手中的兵器，有人使的獨孤九劍，有人使的打狗棒。

最近review代碼有點多，看到了一些很不「講究」的代碼。本篇打算聊聊我作code review的一點心得，先從變量命名這件小事提及吧。

 

使用簡單易識別的單詞

這一條在碼農界應該是公認的吧，不要搞太複雜太生僻的單詞。有些人恰恰喜歡炫本身的英文水平，不考慮其餘同事的感覺。因此起名要用一些很常見的單詞，不要超太高中水平就好了。

好比須要爲「成績」起名，百度一翻譯叫achievement，咱們選score就好。

 

邊界要準確

變量的名字要能準確涵蓋它的含義，不要超出範圍，也不要覆蓋不到。這一點尤爲在給項目或模塊起名字時要注意。

拿咱們公司的來舉例，我見過一個項目叫17zuoye_frontend，感受上是整個公司的前端都在裏面，事實上這只是衆多項目中的一個而已。

還有一個項目，用nodejs重構了前端層，結果把項目命名爲nodejs_front，感受讓人摸不着邊界。

名字起過小了也不行，未來加別的功能會很彆扭。比如你的的招牌掛着黃燜雞米飯，裏面卻硬要賣烤鴨。

 

符合語義

代碼是給人看的，或許是給別人，或許是給幾個月後的本身。因此描述必定要準確，不要使用語義上有明顯出入的名字。

前幾天review一個同事的代碼，看到這麼一行：clientName = true;

我當時就比較懵，這個單詞明明是「客戶端名稱」的意思，怎麼會給賦值爲true呢？詢問以後才知道他要在clientName爲某個值的時候判斷是否展現頭部，爲了使用方便就直接這麼寫了。

所謂語義就是，要符合天然語言的表述習慣。新手常常會有這樣的想法，只要代碼能跑通，變量和邏輯是否「語義正確」不聞不問。其實這是很很差的，這樣的代碼會愈來愈難維護，最後本身寫的本身都看不懂。

說到語義還有一點，那就是不要使用太通用的單詞，好比value、data這些。都表示一個值，可是徹底無從知道它表明的是什麼值，最好起具體的名字。

 

函數名稱

有一個同事使用的單詞卻是很簡單，好比頁面有一個選中標籤頁的功能，他給函數命名爲select。這樣的問題在於，若是頁面中還有其餘的選擇功能該怎麼辦呢？在看代碼的時候，光看到select徹底不知道是要選什麼。

因此在給函數命名的時候，我強烈推薦動-賓結構，好比selectTab、checkPrice，有動詞有賓語，看代碼的是就很容易能對應到頁面功能上去。

 

屬性名稱

關於屬性的命名也一樣，看了名字就立馬能在頁面找到最好。好比你把導航欄叫nav，就不如叫leftNav好，這樣我立馬就知道是頁面左側的導航欄，而不是頂部。

其實這和咱們的天然語言是很相似的，我說「腦殼」，你不知道我想說啥，我說「周杰倫的腦殼」，你腦海中立馬就有影像了。因此屬性的命名要用偏正短語，說白了就是「xxx的xxx」這樣的結構。

 

以上是最近review代碼時關於變量命名的一些感想，再次強調一下，不要覺得程序能跑通就萬事大吉了。代碼是你的思惟的展示，混亂的命名行爲只能說明你的思惟是不清晰的。 感受有不妥的地方，立馬全局替換，不留後患。