編碼品質與命名

很多人以為提高編碼品質，需要很多激動人心的創新，需要明顯的飛躍，這也許對，

但我個人感覺項目中提高編碼品質是個水磨功夫，要一步步積累，方法論大多時候協助不大。

 

這次先從命名說起。

 

 

當我們看到一份設計圖或一份代碼時，大多數人會【望文生義】。但使人【望文生義】卻正是語言文字的根本使命。

因此，如果一個函數被命名為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，《代碼大全》一書中給出了詳細的指導，這裡就不在說明了。

有一點需要補充的是，就和說話的時候記不住文法一樣，設計或做編碼的人往往也記不住編碼規則。所以規則也不宜過多。如果必須詳細，那麼至少要主次分明。比如說：統一使用主賓結構還是使用動賓結構這樣的選擇會影響程式的大部分內容，那麼就應該優先統一。