當妳想到某個抽象的東西，妳更傾向於最先想到的詞語，除非妳故意不這樣，這些詞也會搶著出現，直到模糊或改變妳的想法。
當妳想到壹個具體的對象，妳覺得詞窮，然後妳想描述的已經看到了，然後妳繼續尋找更適合它的詞。
哈哈，命名竟成了編程中最難的事~
Martin Fowler曾經在壹篇文章中曾經引用過Phil Karlton的話：
There are only two hard things in Computer Science: cache invalidation
and naming things.
他說這句話在很長的壹段時間內都是他最喜歡的話。可見命名對於廣大的程序員來說的確是個大問題。
對於我們中國人來說，問題可能出在兩個方面：
– 自打學編程開始就沒被教育過要重視命名。
這可以在譚浩強的《C語言入門》壹書中可見壹斑。《C語言入門》可以說是很多程序員在大學時學習的第壹門編程語言使用的教材。而本書通篇都是各種
a,b,c，x,y,z 的命名方式。這種poor naming的方式被廣大程序員紛紛效仿，導致如今在很多項目代碼中隨處可見。
– 命名需要壹定的英文功底，而國內程序員的英文水平參差不齊。
很多程序員被教育後開始逐漸重視命名，但是受限於英文水平，不知道使用什麽合適的英文詞匯來命名。有的甚至直接把中文直譯為英文的方式命名，或者直接用拼音來命名，反而得不償失。
命名的重要性我想不需要過於強調。如今的軟件開發早已不是求伯君那種單槍匹馬的時代。妳寫下的每壹行代碼都會在不久的以後被團隊的其他人甚至妳自己多次查看。如果是個開源項目，那麽更會被全球各地的人查看源代碼。所以代碼的可讀性就變得尤為重要。如果讀者能夠輕松讀出妳的代碼的意圖，那麽就說明妳的命名功底相當紮實。
比如在壹個管理系統中，妳使用這樣的代碼： a = b * c
很容易讓人摸不著頭腦，雖然程序能夠正常運作，但恐怕沒人敢輕易修改這行他們不了解的代碼。而如果修改成為這樣： weeklypay =
hours_worked * pay_rate; 那恐怕極少有人不懂這行代碼的意圖。
糟糕的命名也會導致大量無謂的註釋，這是壹個很容易跳進去的陷阱。下壹段代碼怕別人不明白妳的意圖，那麽就加上註釋。這貌似是壹個很精妙的想法，實際上卻南轅北轍。比如以下的註釋：
int d; // elapsed time in days
貌似很容易讓人讀懂，但是問題還是很多。首先註釋不能跟著所有的引用，在定義處了解了d的含義，繼續往下看的話卻很容易忘記；其次代碼更新了，很可能會忘記修改註釋，反而給把讀者帶入歧途。
與其用這樣的註釋，還不如直接重命名： int elapsedTimeInDays; 這樣清晰易懂，還不用維護註釋，何樂而不為？
那麽如何著手來提高的自己的命名技巧那？
首先尋找壹份公認的代碼規範，並嚴格按照這樣的標準執行。比如google開源了自己內部使用的語言編碼規範，我們可以直接拿來使用。比如請看Google
Java的style guide，相當詳實。除此之外還有C++等。這裏收集了Google對各種語言的編碼規範，非常具有參考價值。
標準的代碼規範中的每壹條都是有勝出的理由，值得我們遵從。但某些命名問題不壹定只有壹種最好的解決方式，這就需要團隊自己建立起約定。比如對於Java單元測試類的命名方式，不同的團隊可能不壹樣。比如有的團隊喜歡以should開頭，有的喜歡test開頭，有的喜歡駱駝命名法，有些喜歡下劃線命名法，每種方式有各自的利弊，沒有壹種能完全脫穎而出，所以需要團隊自行制定。壹旦確定使用某壹種，那麽壹定要保持壹致。
某些命名規範其實是可以進行自動化檢查的，比如在Java應用的構建過程中可以引用checkStyle這款插件，對命名進行壹些基本的檢查，比如方法名、變量名是否遵循了壹定模式等。這樣在壹定程度上可以強制大家遵守某些約定。自己以前曾經寫過壹篇文章，請參見這裏。
最後要在團隊中建立起code review的機制，通過code
review來相互監督糾正命名問題，並且這樣更容易達成壹致的命名約定，方便協作開發。code
review可以采取非正式會議評審的方式。最簡單的方式就是每天找個固定時間大家壹起聚在壹個顯示器前review每個人的代碼，現場提出問題，當事人記錄下來會後更改。這種方式非常高效。另外有的團隊在嵌入代碼時可能會引入壹些代碼評審機制，比如pull
request， cherry pick等。這種review方式比較重量級，反饋周期也較長，好處是可以保證最終遷入的代碼是沒有問題的。
很多語言和框架為了更加可讀，都把命名玩出花來了。比如JavaScript生態圈中重要的單元測試工具Jasmine把測試函數以it命名，這樣可以與參數連接起來成為壹種表意的自然語言：
如何優雅地為程序中的變量和函數命名？
- 不同的代碼段采用不同的命名長度。通常來說，循環計數器（loop
counters）采用1位的單字符來命名，循環判斷變量（condition/loop
variables）采用1個單詞來命名，方法采用1-2個單詞命名，類采用2-3個單詞命名，全局變量采用3-4個單詞命名。
- 對變量采用具體的命名（specific names）方式，”value”, “equals”,
“data”在任何情況下都不是壹種有效的命名方式。
- 采用有意義的命名（meaningful names）。變量的名字必須準確反映它的含義和內容。
- 不要用 o_, obj_, m_ 等前綴命名。變量不需要前綴標簽來表示自己是壹個變量。
- 遵循公司的變量命名規則，在項目中堅持使用同壹種變量命名方式。例如txtUserName, lblUserName,
cmbSchoolType等，否則會對可讀性造成影響，而且會令查找/替換工具（find/replace tools）不可用。
- 遵循當前語言的變量命名規則，不要不統壹（inconsistently）地使用大/小寫字母。例如：userName, UserName,
USER_NAME, m_userName, username, …。
以Java為例:
* 類名使用駝峰命名法（Camel Case）：VelocityResponseWriter
* 包名使用小寫：com.company.project.ui
* 變量使用首字母小寫的駝峰命名法（Mixed Case）：studentName
* 常量使用大寫:MAX_PARAMETER_COUNT = 100
* 枚舉類（enum class）采用駝峰命名法，枚舉值（enum values）采用大寫。
* 除了常量和枚舉值以外，不要使用下劃線’_’
- 在同壹個類不同的場景（contexts）中不要復用變量名。例如在方法、初始化方法和類中。這樣做可以提高可讀性和可維護性。
- 不要對不同使用目的的變量使用同壹個變量名，而是賦予它們不同的名字。這同樣對保持可讀性和可維護性很重要。
- 變量名不要使用非ASCII字符（non-ASCII chars）。這樣做可能會在跨平臺使用時產生問題。
-
不要使用過長的變量名（例如50個字符）。過長的變量名會導致代碼醜陋（ugly）和難以閱讀（hard-to-read），還可能因為字符限制在某些編譯器上存在兼容性問題。
- 僅使用壹種自然語言（natural language）來命名變量。例如，同時使用德語和英語來命名變量會導致（理解）不壹致和降低可讀性。
- 使用有意義的方法名。方法名必須準確表達該方法的行為，在多數情況下以動詞（verb）開頭。（例如：createPasswordHash）
- 遵循公司的方法命名規則，在項目中堅持使用同壹種方法命名方式。例如 getTxtUserName(), getLblUserName(),
isStudentApproved()，否則會對可讀性造成影響，而且會令查找/替換工具不可用。
- 遵循當前語言的變量命名規則，不要不統壹地使用大/小寫字母。例如：getUserName, GetUserName, getusername,
…。
以Java為例:
* 方法使用首字母小寫的駝峰命名法：getStudentSchoolType
* 方法參數使用首字母小寫的駝峰命名法：setSchoolName(String schoolName)
- 使用有意義的方法參數命名，這樣做可以在沒有文檔的情況下盡量做到“自解釋（documentate itself）”
總之，命名問題只是整個編碼規範中的壹小部分，但是起的作用舉足輕重，它是判斷壹個程序員是否專業的必要標準。