成長指南
提升代碼的可讀性
如何提高代碼的可讀性是一個永恒的話題。
通常認為程式員需要具備較強的“數學”功底，畢竟要掌握各類算法和模式都需要很強的邏輯思維能力。然而在經曆了一段工作時間後，我發現程式員的“國文”能力也同樣重要。《重構》一書就提出：唯有優秀的程式員才能夠寫出人類能了解的代碼。軟體的規模越來越大，一個系統通常需要幾代程式員來開發維護。然而這些程式員們往往都素未謀面，隻能“神交”于代碼的字裡行間。
提到可讀性，其實涉及兩個方面：一是作者的表達能力，二是讀者的了解能力。比如我個人總認為自己在閱讀文字時存在閱讀障礙，然而閱讀代碼卻較有心得。因為我很樂于去揣摩代碼作者的意圖，特别是在遇到一些很晦澀的代碼時。
在實際工作中也經常聽到一些程式員抱怨：這樣的代碼簡直無法維護，還不如推倒重寫。如果你也碰到這種情況，我想請你先思考，是自己的了解能力問題，還是原作者的表達能力問題？然後再決定下一步動作。同時我也總結了一條心得和讀者分享：真正的高手不但要能寫得出好代碼，還要能駕馭得了“爛”代碼。
我曾自我剖析造成閱讀障礙的原因，主要是閱讀量不夠。我的确不愛讀書，但我卻讀（調試）過很多開源軟體代碼。我接觸的第一個開源軟體叫SoX，它是一款Linux下的音頻處理軟體，支援多種音頻格式。我花了很長時間去調試，不僅搞懂了它的架構和算法，還把其中一部分代碼用到了自己開發的軟體裡。後來讀了《設計模式》一書才意識到，SoX實際上是用C語言實作了一個政策（strategy）模式來支援各種音頻格式。
從國文的角度看，代碼的文體應該屬于說明文或記叙文，要着眼于把事情說清楚，而并非詩歌、散文或小說，文中存在着很多暗喻和伏筆，需要讀者揣摩。本章主要讨論表達能力方面的問題，即：代碼如何能清晰地表達作者的意圖，讓人易于了解。
唐代大詩人白居易，史書評價其詩：“每成篇，必令其家老妪讀之，問解則錄。”意思是他每次寫完詩，就會讓家裡的老婆婆讀，老婆婆能讀懂的話，才會編輯入冊。
提升代碼可讀性重要法則：設定縮進
我在Z公司時，公司有一條程式設計規範是縮進必須為4個空格。但我從來沒有遵守過，一直我行我素地按照我的風格：縮進1個Tab并且在Source Insight裡把Tab設定為8個空格。幸運的是從來沒有人找過我的“麻煩”。
後來到了H公司也有一條相同的程式設計規範。當我繼續按照自己的風格寫代碼時，Pc-lint（一種C/C++代碼靜态分析工具）報錯了。于是不得不遵守這條規範。但在離開H公司後我還是繼續按照我的風格寫代碼。
縮進為1個Tab并且把Tab設定為8個空格，這其實也是Linux核心的程式設計規範，我很認可并一直使用。這麼設定至少有以下幾個好處：
1）當代碼嵌套層次過多時，代碼就會比較靠右，這樣更容易發現問題，并及時優化。
2）可以在代碼編輯器中把字型設定得稍小一點，代碼看起來也會很有層次。這樣在單屏裡面能夠裝下更多代碼，友善閱讀。
3）如果确實有人對8個空格不适應，還有折中的餘地，他可以在自己的IDE中把Tab設定為4個空格。這樣對大家都沒有影響。
一種反對的觀點認為switch…case…語句會過于靠右，因為通常的做法是case關鍵字較switch關鍵字多一層縮進。使用Tab對應8個空格作為縮進時，代碼會像下面這樣。
case關鍵字和switch之間已經有了一個Tab，而case内部的處理代碼又多了一個Tab，從開始寫case下的主要代碼時，左邊就已經有了24個空格（3個Tab），使得代碼更加靠右。然而通過調整switch…case…語句的排布方式可以解決這個問題，讓case和switch語句對齊，像下面這樣排布代碼，層次清晰也沒有造成多餘的縮進。
還有一種反對的觀點認為使用Tab作為縮進會令代碼在不同的編輯器中排布效果不一樣。比如同一份代碼在Visual Studio中能對齊，但在UltraEdit中卻不能對齊。
實際上就縮進而言，隻要Tab和空格不混用，是不會出現上述情況的。出現上述情況是因為使用Tab鍵控制代碼左右的間隔來達到對齊效果。比如下面這部分代碼，如果在某個編輯器中是在等号“=”左邊使用了若幹Tab鍵使得“=”保持在同一豎線。那麼用其他編輯器打開同一個檔案時可能會出現“=”不在同一豎線的情況。比如下面的代碼塊在Visual Studio中對齊。
但用UltraEdit打開時可能會是如下這樣，最後一個“=”沒有與上面的對齊。
原因是使用Tab控制代碼的左右間距時，編輯器會使用某種适配算法根據Tab鍵所設定的對應空格數來顯示Tab的長度。不同的編輯器算法不同，是以可能存在不一樣的對齊效果。而使用空格就不會出現這類情況。是以推薦使用的代碼排布方式為：在縮進時使用Tab，在其他代碼塊對齊時使用空格。這樣就能達到代碼在各種編輯器中保持同樣效果的目的。如下所示。