什么代碼才是好代碼？這真是個老得能拔掉牙齒的話題。好吧，那讓我們再在這刮沙塵暴的無聊時光里重復一次。好的代碼要是易讀的代碼、要做到職責分離、要做到單一職責、要有高的執行效率....

　　等等，等等，這才抽象了，太書面化了。我只是一個菜鳥，剛寫代碼幾年，也沒念過什么書，能不能說得通俗易懂一些？

　　好吧，我停下來，想，這真是個難纏的家伙。我說，這樣吧，我推薦幾本書你去看吧，《重構》熊節最近再版了，建議你去買一本。恩，等等，有個省錢的招，去圖靈俱樂部討論組注冊下，蹭贈書也很爽，哈哈。

　　可是，你還沒告訴我什么代碼才是好代碼呢？知道你也沒什么好答案，我自己來說好了。

　　省略掉此時我內心花花的汗水，下面是菜鳥的敘述：

　　1. 一致

　　我發現自己有輕微的強迫癥，當我碰到以下代碼時，我就會沖動。

　　沖動前代碼：

def imgName
if(XXX){
   imgName="meigui"
}else{
   imgName=""
}

　　沖動后代碼：

def imgName=XXX?"meigui":""

　　盡管兩段代碼功能一致，但一旦我發現出現沖動前代碼時，我就會感到不舒服，感到難受，就好像看到閱兵正步走不齊一樣。方法名也是一樣：

　　沖動前：

　　def testXXX(){}

　　沖動后：

　　def should_XXX_when_XXX(){}

　　變量亦是如此:

　　沖動前：

　　def imgNode=resouce.adoptTo(Node)

　　沖動后：

　　def node=resouce.adoptTo(Node)

　　總之，我不愿意看到同一個事情有兩種實現方式，如果功能類似，那么不管是邏輯還是變量、方法名，我會強迫一致，整齊劃一。

　　關于一致，從調試代碼的角度看，零星的不一致比大量的不一致更加糟糕，因為這時大部分地方的一致性會令人麻痹大意。在實現查詢分頁功能時，我們有這樣一行代碼：

　　nodeIterator.size

　　這行代碼的意思是獲取查詢結果的總數，大部分情況下它工作良好，但是在一種特殊情況下它返回了-1。這對我當時幾乎是災難性的，因為調試過程中我們始終相信這行代碼的行為一致，結果是花費了一個下午才找到這個問題。

　　2. 簡潔

　　我喜歡短的代碼，對我而言，短的程序總是比更長一些的代碼容易理解，小學時學課文就已經這樣了，一看到大段的段落我總是會暈過去（特別是文言文，首先我就對自己理解這段文字失去了信心）。這里要提到注釋，即是這些注釋明確是為了提高代碼的可讀性，也會增加我閱讀代碼的困難，所以我不會在方法里的任何位置添加注釋，撐死在個別方法聲明前添加，并且這種情況也盡量避免，如果這個類確實包含了重要的不易理解的算法，我也只會在類聲明前添加注釋。

　　關于自然語言，有一個基于經驗的結論被稱為Zipf定律，即：自然語言中最常用到的單詞，其長度會趨于最短。

　　我寫代碼的時候，能夠簡寫盡量簡寫，例如，變量名，imageNode，我一定會寫成imgNode；方法名procedureXXX,我一定會寫成procXXX，和討厭大段代碼一樣，我非常討厭命名很長的方法名和變量名，盡管這些名稱這么長是為了更好的增加可讀性，但可讀性不是這樣增加的。

　　在我的第一份代碼工作里，我們使用拼音來命名方法和變量（還好，沒有包括類名），我討厭這種命名方式的原因并不是因為我的語文老師不好以至于我前后鼻音不分，而是這種寫法根本排除了簡寫的可能性，甚至，為了避免歧義，有時不得不變得更長。

　　3. 聯覺和順序

　　關于記憶，人類有兩種重要的記憶能力：聯覺和順序記憶。

　　關于聯覺，一個例子是：你總可以一眼記住一個人的臉，比如范冰冰，盡管我到現在也不清楚她到底是單眼皮還是雙眼皮，也不清楚她到底是厚嘴唇還是薄嘴唇。

　　那么，在代碼里，這里的表現就是局部，即一個功能的所有相關代碼都集中在一個地方。我最討厭的代碼是這樣的：最開始我打開一個文件，在閱讀的過程中，我發現一個不清楚的方法，于是我按下ctrl并點擊鼠標，于是我跳到另外一個文件；接下來，在閱讀另外一個方法里，我再次發現了一個不清楚的方法，于是我再次按下ctrl并點擊鼠標，哇哈，新的文件打開了....如此反復，終于當我打開最后一個文件時，我發現IDE的文件條里已經密密麻麻的排滿了好幾排文件。于是，我移動鼠標，右鍵，彈出一個關閉菜單，我選擇了close others，瞬間，哦米拖佛，整個世界清靜了，但是，等等，我最初是打算干嘛來著？

　　所以，請把所有相關聯的代碼都集中在一個地方，求您了。哦，對了，能不用接口請不要用接口，總會碰到這樣的情況，打開好幾排的文件，接口文件占了一半，我靠，少幾個接口會死啊。對了，這可能是您的一致性心理在作怪，對不起，對不起。

　　關于局部，一個范例同樣與調試有關，在很久之前的一次調試中，我們始終找不到一個變量錯誤的原因，因為在這段代碼里，根本找不到任何錯誤。很久以后，終于發現，這個變量竟然是個全局變量，嘿嘿，告訴你吧，這個變量在servlet里，04年的時候，網上很火的一篇文章，標題就是：不要在servlet里使用全局變量！

　　關于順序，最典型的例子出現在高中化學里，我總也不能瞬間說出第12、13個化學元素是什么，我通常會這樣記憶：氫氦鋰鈹硼碳氮氧氟氖鈉鎂鋁硅磷，啊哈，第12個元素是鎂，第13個元素時鋁，合起來就是--美女！

　　所以，在代碼里，請將互相調用的方法按順序擺放，方法1先調用了方法2，那么請將方法2緊放在方法1后邊。我討厭這樣的配置：打開方法1，發現其調用了方法2，點擊方法2，編輯器里的滾動條瞬間從最上端滾到最下端，緊接著，滾動條又從最下端滾動到中間，再接著，又是最下端，接著，歸零到最上端....人生經不起這樣的大起大落，真的，那得要多么大的心臟啊，麥蒂才有過那么一次，13秒....

　　還有，知道為什么goto為什么那么臭名昭著了吧。

　　4. 自然

　　使得代碼具有輕松的表達方式，同時把錯誤率降到最低，一種最重要的方法就是代碼變得“自然”，即向自然語言靠攏。因為代碼并不僅僅是與機器交流的，更重要的是，需要在人之間交流。

　　機器語言到高級語言，面向過程語言到面向對象語言，jdbc到hibernate，java到動態語言，這些都促使代碼變得更加自然。

　　Ruby里有個不起眼的特性，就是方法調用不用再寫括號，這一特性是如此的微不足道但是卻被很多人津津樂道，原因就是它更加自然，更加貼近我們的自然語言。于是，我看到，我的同事曉娜，在groovy里，一遍遍的將她力所能及的括號去掉。

　　此外，程序語言和自然語言是有區別的，除了不能在代碼里利用感情詞抒發情感之外（我想，如果可以，一定會看到很多的馮特），程序語言沒有口語。很少看到程序員之間這樣交流，來吧，我們來說段代碼（當然也有，徐昊就可以，哈哈），他們更多的會使用白板和筆或者直接是編輯器。所以，結束招聘時是否需要筆試的爭論吧，我真為那些不經過筆試就直接招人的公司感到羞愧，因為他們根本就不懂程序語言。

　　此處省略華麗的分割線。

　　此文謝謝我們項目組WGSN的激烈討論，謝謝討論中徐昊的精彩點評。