|
|
什么代碼才是好代碼？這真是個(gè)老得能拔掉牙齒的話題。好吧，那讓我們再在這刮沙塵暴的無聊時(shí)光里重復(fù)一次。好的代碼要是易讀的代碼、要做到職責(zé)分離、要做到單一職責(zé)、要有高的執(zhí)行效率....
等等，等等，這才抽象了，太書面化了。我只是一個(gè)菜鳥，剛寫代碼幾年，也沒念過什么書，能不能說得通俗易懂一些？
好吧，我停下來，想，這真是個(gè)難纏的家伙。我說，這樣吧，我推薦幾本書你去看吧，《重構(gòu)》熊節(jié)最近再版了，建議你去買一本。恩，等等，有個(gè)省錢的招，去圖靈俱樂部討論組注冊下，蹭贈(zèng)書也很爽，哈哈。
可是，你還沒告訴我什么代碼才是好代碼呢？知道你也沒什么好答案，我自己來說好了。
省略掉此時(shí)我內(nèi)心花花的汗水，下面是菜鳥的敘述：
1. 一致
我發(fā)現(xiàn)自己有輕微的強(qiáng)迫癥，當(dāng)我碰到以下代碼時(shí)，我就會(huì)沖動(dòng)。
沖動(dòng)前代碼：
def imgName
if(XXX){
imgName="meigui"
}else{
imgName=""
}
沖動(dòng)后代碼：
def imgName=XXX?"meigui":""
盡管兩段代碼功能一致，但一旦我發(fā)現(xiàn)出現(xiàn)沖動(dòng)前代碼時(shí)，我就會(huì)感到不舒服，感到難受，就好像看到閱兵正步走不齊一樣。方法名也是一樣：
沖動(dòng)前：
def testXXX(){}
沖動(dòng)后：
def should_XXX_when_XXX(){}
變量亦是如此:
沖動(dòng)前：
def imgNode=resouce.adoptTo(Node)
沖動(dòng)后：
def node=resouce.adoptTo(Node)
總之，我不愿意看到同一個(gè)事情有兩種實(shí)現(xiàn)方式，如果功能類似，那么不管是邏輯還是變量、方法名，我會(huì)強(qiáng)迫一致，整齊劃一。
關(guān)于一致，從調(diào)試代碼的角度看，零星的不一致比大量的不一致更加糟糕，因?yàn)檫@時(shí)大部分地方的一致性會(huì)令人麻痹大意。在實(shí)現(xiàn)查詢分頁功能時(shí)，我們有這樣一行代碼：
nodeIterator.size
這行代碼的意思是獲取查詢結(jié)果的總數(shù)，大部分情況下它工作良好，但是在一種特殊情況下它返回了-1。這對我當(dāng)時(shí)幾乎是災(zāi)難性的，因?yàn)檎{(diào)試過程中我們始終相信這行代碼的行為一致，結(jié)果是花費(fèi)了一個(gè)下午才找到這個(gè)問題。
2. 簡潔
我喜歡短的代碼，對我而言，短的程序總是比更長一些的代碼容易理解，小學(xué)時(shí)學(xué)課文就已經(jīng)這樣了，一看到大段的段落我總是會(huì)暈過去（特別是文言文，首先我就對自己理解這段文字失去了信心）。這里要提到注釋，即是這些注釋明確是為了提高代碼的可讀性，也會(huì)增加我閱讀代碼的困難，所以我不會(huì)在方法里的任何位置添加注釋，撐死在個(gè)別方法聲明前添加，并且這種情況也盡量避免，如果這個(gè)類確實(shí)包含了重要的不易理解的算法，我也只會(huì)在類聲明前添加注釋。
關(guān)于自然語言，有一個(gè)基于經(jīng)驗(yàn)的結(jié)論被稱為Zipf定律，即：自然語言中最常用到的單詞，其長度會(huì)趨于最短。
我寫代碼的時(shí)候，能夠簡寫盡量簡寫，例如，變量名，imageNode，我一定會(huì)寫成imgNode；方法名procedureXXX,我一定會(huì)寫成procXXX，和討厭大段代碼一樣，我非常討厭命名很長的方法名和變量名，盡管這些名稱這么長是為了更好的增加可讀性，但可讀性不是這樣增加的。
在我的第一份代碼工作里，我們使用拼音來命名方法和變量（還好，沒有包括類名），我討厭這種命名方式的原因并不是因?yàn)槲业恼Z文老師不好以至于我前后鼻音不分，而是這種寫法根本排除了簡寫的可能性，甚至，為了避免歧義，有時(shí)不得不變得更長。
3. 聯(lián)覺和順序
關(guān)于記憶，人類有兩種重要的記憶能力：聯(lián)覺和順序記憶。
關(guān)于聯(lián)覺，一個(gè)例子是：你總可以一眼記住一個(gè)人的臉，比如范冰冰，盡管我到現(xiàn)在也不清楚她到底是單眼皮還是雙眼皮，也不清楚她到底是厚嘴唇還是薄嘴唇。
那么，在代碼里，這里的表現(xiàn)就是局部，即一個(gè)功能的所有相關(guān)代碼都集中在一個(gè)地方。我最討厭的代碼是這樣的：最開始我打開一個(gè)文件，在閱讀的過程中，我發(fā)現(xiàn)一個(gè)不清楚的方法，于是我按下ctrl并點(diǎn)擊鼠標(biāo)，于是我跳到另外一個(gè)文件；接下來，在閱讀另外一個(gè)方法里，我再次發(fā)現(xiàn)了一個(gè)不清楚的方法，于是我再次按下ctrl并點(diǎn)擊鼠標(biāo)，哇哈，新的文件打開了....如此反復(fù)，終于當(dāng)我打開最后一個(gè)文件時(shí)，我發(fā)現(xiàn)IDE的文件條里已經(jīng)密密麻麻的排滿了好幾排文件。于是，我移動(dòng)鼠標(biāo)，右鍵，彈出一個(gè)關(guān)閉菜單，我選擇了close others，瞬間，哦米拖佛，整個(gè)世界清靜了，但是，等等，我最初是打算干嘛來著？
所以，請把所有相關(guān)聯(lián)的代碼都集中在一個(gè)地方，求您了。哦，對了，能不用接口請不要用接口，總會(huì)碰到這樣的情況，打開好幾排的文件，接口文件占了一半，我靠，少幾個(gè)接口會(huì)死啊。對了，這可能是您的一致性心理在作怪，對不起，對不起。
關(guān)于局部，一個(gè)范例同樣與調(diào)試有關(guān)，在很久之前的一次調(diào)試中，我們始終找不到一個(gè)變量錯(cuò)誤的原因，因?yàn)樵谶@段代碼里，根本找不到任何錯(cuò)誤。很久以后，終于發(fā)現(xiàn)，這個(gè)變量竟然是個(gè)全局變量，嘿嘿，告訴你吧，這個(gè)變量在servlet里，04年的時(shí)候，網(wǎng)上很火的一篇文章，標(biāo)題就是：不要在servlet里使用全局變量！
關(guān)于順序，最典型的例子出現(xiàn)在高中化學(xué)里，我總也不能瞬間說出第12、13個(gè)化學(xué)元素是什么，我通常會(huì)這樣記憶：氫氦鋰鈹硼碳氮氧氟氖鈉鎂鋁硅磷，啊哈，第12個(gè)元素是鎂，第13個(gè)元素時(shí)鋁，合起來就是--美女！
所以，在代碼里，請將互相調(diào)用的方法按順序擺放，方法1先調(diào)用了方法2，那么請將方法2緊放在方法1后邊。我討厭這樣的配置：打開方法1，發(fā)現(xiàn)其調(diào)用了方法2，點(diǎn)擊方法2，編輯器里的滾動(dòng)條瞬間從最上端滾到最下端，緊接著，滾動(dòng)條又從最下端滾動(dòng)到中間，再接著，又是最下端，接著，歸零到最上端....人生經(jīng)不起這樣的大起大落，真的，那得要多么大的心臟啊，麥蒂才有過那么一次，13秒....
還有，知道為什么goto為什么那么臭名昭著了吧。
4. 自然
使得代碼具有輕松的表達(dá)方式，同時(shí)把錯(cuò)誤率降到最低，一種最重要的方法就是代碼變得“自然”，即向自然語言靠攏。因?yàn)榇a并不僅僅是與機(jī)器交流的，更重要的是，需要在人之間交流。
機(jī)器語言到高級語言，面向過程語言到面向?qū)ο笳Z言，jdbc到hibernate，Java到動(dòng)態(tài)語言，這些都促使代碼變得更加自然。
Ruby里有個(gè)不起眼的特性，就是方法調(diào)用不用再寫括號，這一特性是如此的微不足道但是卻被很多人津津樂道，原因就是它更加自然，更加貼近我們的自然語言。于是，我看到，我的同事曉娜，在Groovy里，一遍遍的將她力所能及的括號去掉。
此外，程序語言和自然語言是有區(qū)別的，除了不能在代碼里利用感情詞抒發(fā)情感之外（我想，如果可以，一定會(huì)看到很多的馮特），程序語言沒有口語。很少看到程序員之間這樣交流，來吧，我們來說段代碼（當(dāng)然也有，徐昊就可以，哈哈），他們更多的會(huì)使用白板和筆或者直接是編輯器。所以，結(jié)束招聘時(shí)是否需要筆試的爭論吧，我真為那些不經(jīng)過筆試就直接招人的公司感到羞愧，因?yàn)樗麄兏揪筒欢绦蛘Z言。
此處省略華麗的分割線。
此文謝謝我們項(xiàng)目組WGSN的激烈討論，謝謝討論中徐昊的精彩點(diǎn)評。
it知識(shí)庫：再談好代碼，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
