程式碼好似程式設計師手中的兵器，有人使的獨孤九劍，有人使的打狗棒。
最近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程式碼時關於變數命名的一些感想，再次強調一下，不要以為程式能跑通就萬事大吉了。程式碼是你的思維的展現，混亂的命名行為只能說明你的思維是不清晰的。 感覺有不妥的地方，立馬全域性替換，不留後患。