最近在讀一些書，想和大家分享下讀書的樂趣和學到的知識。目前讀書的系列大都是專業相關的，例如《Clean Code, 《Refactoring-Improving the design of the existing code》, 《Pro-Objective-C Design Pattern for iOS》等等(有些是重讀)。當然還有《out of control》這類午后讀物。多讀書，多看報，提升自己，排解寂寞。
這篇我們來分享讀《Clean Code》(代碼整潔之道)第二章節的讀后感。
第二章節講的事Meaningful Names, 意思是在我們寫代碼時，需要用到有意義能自我解釋的命名方式。這部分內容不涉及技術，但是可以幫助我們寫出能讓他人和未來的自己讀懂的代碼。我會結合書中的標準和我寫iOS程序的經驗來批判的接受和修改一些書中的內容。
Use Intention-Revealing Names(使用'顧名思義'的名稱)
這個很好理解，在我們寫程序的時候，無論變量，函數，參數，類等的名稱，都應該遵循這個標準。因為它可以很好地幫助你，或者其他程序員理解你的程序，理解你的變量或代碼片段的目的。下面是書中的例子:
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
這段代碼是干什么的呢？其實細細去讀也不難發現這就是將某個list中值為4的數組加入另一個list(其實就是篩選的功能)。但是這樣的代碼讓人很頭疼，我在工作中也最煩遇到這樣的代碼，一般來說，只有很抽象的算法代碼才會寫成這樣。閱讀者會對這類代碼產生很多問題，例如:
- theList到底是干嘛的，包含什么?
- x[0]是什么，包含什么？
- 4又代表什么?
- list1返回后怎么用？
下面是改良版的程序:
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
重命名之后，我們可以輕易看出這估計是個(國際)象棋游戲，標記位的cell被取出。
Avoid Disinformation (避免虛假命名)
一言以蔽之就是不要使用那些會混淆代碼理解，或者錯誤的命名。例如不要和系統的關鍵字重復或特別相近, hp,aix,sco這類的前綴或者變量名不可使用，因為這是UNIX
系統內部名稱。還有就是在命名一些特定數據結構時要謹慎，例如你有一對account，你可以命名成 bunchOfAccounts 或者 accountGroup 抑或accounts.書中不建議使用accountList，除非它真的是一個list結構。對此，仁者見仁，智者見智了。因為看你代碼的也都是程序員，這樣命名個人覺得是可以的，注意不要把Array命名成List。書中還舉了一個'awful'的例子，就是用大寫的'L'和'O'做變量名，類似hot key。要知道'O'和'0'是很像的，所以輕易不要用。
Make Meaningful Distinctions(命名要做有意義的區分)
不同的變量要用不同的名稱區分開來。相信不少同學在命名的時候都用過a1,a2,a3這樣的變量名。這并不好。一些noise的數字不應該出現在本應有意義的名稱中，因為這樣根本體現不出作者的意圖。其實呢，在平常寫一些測試程序的時候，可以圖簡便，這樣寫寫。但是到了項目中，一定要用可區分的名稱。書中還舉到一個例子我覺得很不錯, 如下:
getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();
說實話，我真的不知道用哪個函數來讀取賬戶信息了，這就是典型的區分度做的不夠。
Use Pronounceable Names(用能讀出來的名字)
這個沒什么可說的，上個例子。genymdhms這個變量是干什么的？其實它是代表一種類型的Date，年月日-時秒分，gen代表generate。KK，挺復雜的。改成generationTimestamp就好些了。
Use Searchable Names(使用可搜索的名稱)
我們為什么總強調合理的命名呢？為什么要大家都遵循命名的規范呢？其實無非是想形成一個約定俗成的習慣，讓大家都能進行標準化的開發罷了。當我接手一個項目，當我想找網絡模塊某個功能的時候，我會去想之前的developer會用什么名字命名，例如login部分，register部分等等。這也方便之后的人去查找代碼位置。但如果你命名了一個a3, b4，那查找起來就很吃力了。原書中的例子是:MAX_CLASSES_PER_STUDENT和7哪個好查找？不用說，當然是第一個。
Avoid Encodings(避免編碼化命名)
這個其實遇到的情況不多，除非你是寫底層的(Windows C API). 編碼化命名指的是在name中加入數字，范圍等信息的命名方式。最典型的就是匈牙利命名法。這種命名需要每個新加入的成員好好學習上一番，而且需要更長時間來適應它。具體的匈牙利命名是怎么回事就不在這里多說了，大家可以看這里。
Avoid Mental Mapping(避免心理地圖式命名)
每個程序員都有可能使用一些shortcut(快捷方式)來命名一些長些的名稱，例如用r代替url, co代替commit等等。這種命名當然不好，在項目中不要用。
Class,Method Names(類和方法的命名)
類命名要用名詞性質的詞，例如Customer, WikiPage,而且第一個字母要大寫。原書中說道類名中不要出現動詞，例如Manager, Processor, Data, 但個人覺得此條并不能讓我信服。舉例來說，GFTRequestManager可以讓我很快意識到這是一個控制網絡請求的單例控制類，而且不會和XXXRequest(某個特定請求)重復。至于函數名稱，基本要包含動詞了，例如postNotification這些。
Don't be cute and pun(別犯傻和用雙關語)
不要使用你自己覺得很可愛其實很傻的命名，例如HolyHandGrenade, 老老實實用deleteItems代替。雙關語就不多說了，別讓人理解錯就行。
剩下的部分就是告訴我們也可以添加一些context幫助理解，例如注釋，不過不要讓你的注釋成為累贅，必要的時候再添加。
