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

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

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

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

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

1.一致
我發(fā)現(xiàn)自己有輕微的強(qiáng)迫癥，當(dāng)我碰到以下代碼時，我就會沖動。
沖動前代碼：
def imgName
if(XXX){
   imgName="meigui"
}else{
   imgName=""
}
沖動后代碼：
def imgName=XXX?"meigui":""

盡管兩段代碼功能一致，但一旦我發(fā)現(xiàn)出現(xiàn)沖動前代碼時，我就會感到不舒服，感到難受，就好像看到閱兵正步走不齊一樣。方法名也是一樣：
沖動前：
def testXXX(){}
沖動后：
def should_XXX_when_XXX(){}

變量亦是如此:
沖動前：
def imgNode=resouce.adoptTo(Node)
沖動后：
def node=resouce.adoptTo(Node)

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

關(guān)于一致，從調(diào)試代碼的角度看，零星的不一致比大量的不一致更加糟糕，因?yàn)檫@時大部分地方的一致性會令人麻痹大意。在實(shí)現(xiàn)查詢分頁功能時，我們有這樣一行代碼：
nodeIterator.size
這行代碼的意思是獲取查詢結(jié)果的總數(shù)，大部分情況下它工作良好，但是在一種特殊情況下它返回了-1。這對我當(dāng)時幾乎是災(zāi)難性的，因?yàn)檎{(diào)試過程中我們始終相信這行代碼的行為一致，結(jié)果是花費(fèi)了一個下午才找到這個問題。

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

關(guān)于自然語言，有一個基于經(jīng)驗(yàn)的結(jié)論被稱為Zipf定律，即：自然語言中最常用到的單詞，其長度會趨于最短。

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

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

3.聯(lián)覺和順序
關(guān)于記憶，人類有兩種重要的記憶能力：聯(lián)覺和順序記憶。

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

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

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

關(guān)于局部，一個范例同樣與調(diào)試有關(guān)，在很久之前的一次調(diào)試中，我們始終找不到一個變量錯誤的原因，因?yàn)樵谶@段代碼里，根本找不到任何錯誤，很久以后，終于 發(fā)現(xiàn)，這個變量竟然是個全局變量，嘿嘿，告訴你吧，這個變量在servlet里，04年的時候，網(wǎng)上很火的一篇文章，標(biāo)題就是：不要在servlet里使 用全局變量！

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

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

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

4.自然
使得代碼具有輕松的表達(dá)方式，同時把錯誤率降到最低，一種最重要的方法就是代碼變得“自然”，即向自然語言靠攏。因?yàn)榇a并不僅僅是與機(jī)器交流的，更重要的是，需要在人之間交流。

機(jī)器語言到高級語言，面向過程語言到面向?qū)ο笳Z言，jdbc到hibernate，java到動態(tài)語言，這些都促使代碼變得更加自然。

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

此外，程序語言和自然語言是有區(qū)別的，除了不能在代碼里利用感情詞抒發(fā)情感之外（我想，如果可以，一定會看到很多的馮特），程序語言沒有口語。很少看到程 序員之間這樣交流，來吧，我們來說段代碼（當(dāng)然也有，徐昊就可以，哈哈），他們更多的會使用白板和筆或者直接是編輯器。所以，結(jié)束招聘時是否需要筆試的爭 論吧，我真為那些不經(jīng)過筆試就直接招人的公司感到羞愧，因?yàn)樗麄兏揪筒欢绦蛘Z言。

此處省略華麗的分割線。

此文謝謝我們項(xiàng)目組WGSN的激烈討論，謝謝討論中徐昊的精彩點(diǎn)評。