程序員談編碼質量與命名
這次先從命名說起。
當我們看到一份設計圖或一份代碼時，大多數人會【望文生義】。但使人【望文生義】卻正是語言文字的根本使命。
因此，如果一個函數被命名為Add()，但內部實際做的是減法，那么這份設計或者這份代碼，一定是很難理解的。
于是一個非常現實的問題就擺在了我們的面前：我們究竟應該如何為類，為方法等等命名？
以命名而論，有兩個較大的陷阱：一個是名實不符，一個是詞義混淆。
名實不符的常見情形又有兩類。比如：
以偏概全。假設說一個方法被命名為OutputLineNumber()，但實際上這個方法會在分析源文件后，同時輸出LineNumber和指定行號下的內容大而無當。假使說一個類被命名為XMLHandler，那么看得人基本不能從這個名字上獲得有效信息。這主要是由于Handler這個詞的含義過于寬泛。
上文所說的命名為Add()但實際做減法操作是名實不符的極端情形，達到了名實相反的地步。
詞義混淆則源自語言文字自身的限制。常表現為一詞多義或多詞一義。
語言文字可以被看成是一種表意的符號系統，這個符號系統的典型特征是其模糊性。
同一個意思可以有許多種表達方法。比如說：index和number是兩個不同的詞，但很多時候其意義互相重疊。而假如說一個變量名為fileNumber，那么這個變量既可以代表文件的總數，也可以代表某個具體文件的編號。
上述問題會因為英語不是我們的母語而變得更為麻煩。
名實不符與詞義混淆這類陷阱的一個主要觸發條件是軟件自身的不停衍化。
在之前的文章里曾經提到過，對于概念和邏輯的認知是一個逐層遞進的過程。
在這一過程中，包，類，方法等的內涵必然會發生變更。變更無疑的會使名實不符這類問題加劇。比如：一個類原本負責輸出測試結果，這時候OutputTestResult這樣的命名可能是合適的。可隨著軟件功能的增強，最終可能不知要輸出結果，還要對結果進行一定分析和統計。這樣原來的命名就顯的有些不合適了。
在對命名這一問題的根源進行分析之后，我們來看看可能的應對方法。
命名問題事實上并不能只在命名這一環節進行解決，首先要有容易命名的對象，接下來才有容易命名的事實。
比如說：是先有貓和狗這類外在特征不同的動物，接下來我們才用貓和狗這樣不同的名字來稱呼他們，而非相反。
如果概念之間是正交的，概念的邊界也是清晰的，那么命名無疑會容易很多。好的設計是改善命名的基礎。
也就是說，很多時候我們感到命名困難，真正原因可能并非是命名的技能不夠，而是設計還不夠優化。
在努力改善設計之后，才需要面對純粹的命名問題。
從本質上來看，命名問題并不是一個編程的問題，而是一個表達的問題。命名最終對讀程序的人負責。
有些表達上的基本原則對于解決命名問題會有些幫助，比如：
尊重既成事實
無疑的每個人都是有創造性的，但在命名的時候發揮創造性則更可能是有害的。比如說：在XML的世界中一般使用sibling這個詞來表示兄弟節點，這種時候就不需要創造性的使用brother node這樣的自制詞匯了。
用完整詞匯
對一般人而言要求事先記憶幾十個縮寫詞，而后來讀程序是不太可能的事情。所以如果一個程序中充滿_Tx和CSCP這樣的特制符號的話，那這樣的程序幾乎一定是不容易懂的。
一個典型的反例是P.J Plauger版的C++標準模板庫。也許是出于隱藏實現細節的目的，這份標準模板庫的實現里面幾乎完全不用完整詞匯。如果想體驗一下不用完整詞匯的后果，那么可以讀一下這里面的代碼。
要具體
具體是一個方向。
比如說：可以用OutputLinenumber()的時候，就不要用Output()。而可以用OutputCppLinenumber()的時候就不要用OutputLinenumber()。
多人協作的時候，使用統一規范
這條規則最終會導致常說的Coding Rule。對具體如何定義Coding Rule，《代碼大全》一書中給出了詳細的指導，這里就不在說明了。
有一點需要補充的是，就和說話的時候記不住語法一樣，設計或做編碼的人往往也記不住編碼規則。所以規則也不宜過多。如果必須詳細，那么至少要主次分明。比如說：統一使用主賓結構還是使用動賓結構這樣的選擇會影響程序的大部分內容，那么就應該優先統一。
原文鏈接：http://www.cnblogs.com/daoshi/archive/2012/04/23/2465812.html
【編輯推薦】
