代碼的可讀性好壞，會影響到程序員編寫和維護代碼的過程。如果把人的大腦看作計算機 CPU 加上內存的結合。那麼，需要人去猜測的變量名、沒有良好組織結構的代碼、混亂的佈局，對於閱讀代碼的人來說，總會消耗過多的大腦資源。而這些資源和精力應該放在程序員正在關心的業務上。
下面，我們先來看看程序的一些命名規則。
1、變量名應該完全、準確的描述該變量所代表的事物
a、不是通用或者約定俗成的縮寫，不要用簡寫替代變量名。如將 userinfo 寫成 u 或者 ui 或者 uInfo。閱讀代碼時，類似的名字需要讀者思考的時候繞兩個彎子，甚至需要 Debug 或者聯繫上下文才能明白變量名的意思。
b、大多數情況下，不要使用 user1、user2 來表示同一程序中不同的變量。這樣閱讀代碼的人就無法區分兩個變量的不一樣的地方。
c、不要使用中文甚至中文縮寫命名變量名。
d、通常情況下，不要使用動詞作爲變量名。
2、好的變量名反映的都是問題，而不是解決方案。表達的是 what，而不是 how。
一條員工數據記錄可以稱爲 inputRecord 或者 employeeData。inputRecord 是一個反映輸入、記錄這些計算機概念的術語。employeeData 則能讓人直接聯想到相關業務場景，與計算無關。
3、變量名的長度
相關研究發現，當程序裏的變量名的平均長度在10到16個字符之間的時候，調試程序所需花費的力氣是最小的。
如下圖，感受下不同的變量名給人的感覺。
這裏是一些縮短變量名的指導原則。
1、使用標準的縮寫（如 rpt）。
2、去掉虛詞 and,or,the。
3、使用名字中的每一個重要單詞，最多不超過3個。
4、去掉無用的後綴（如 ing、ed 等）。
5、確保不要改變變量的含義。
6、不要從每個單詞中刪除一個字符的方式來縮寫。
7、縮寫要一致：如果將 function 縮寫成 func。那麼將整個項目裏，最好都統一使用這種縮寫。
4、爲特定的變量命名
a、爲狀態變量取一個比 flag 更好的名字。如用 reportType 而不是 flag 作爲變量名。
b、臨時變量不要使用 temp。
c、爲布爾變量命名。done、error、found、success 在具體的場景下，都是很有用的變量名。而 sourceFile 是很糟糕的變量名，因爲他沒有明確的 true 或者 false。if(found) 的可讀性要高於 if(isFound)。
參考資料：《代碼大全》