有多少程序員，就有多少定義。所以我只詢問了一些非常知名且經(jīng)驗豐富的程序員。

　　Bjarne Stroustrup，C++語言發(fā)明者，C++ Programming Language（中譯版《C++程序設(shè)計語言》）一書作者。
　　我喜歡優(yōu)雅和高效的代碼。代碼邏輯應(yīng)當(dāng)直截了當(dāng)，叫缺陷難以隱藏；盡量減少依賴關(guān)系，使之便于維護；依據(jù)某種分層戰(zhàn)略完善錯誤處理代碼；性能調(diào)至最優(yōu)，省得引誘別人做沒規(guī)矩的優(yōu)化，搞出一堆混亂來。整潔的代碼只做好一件事。
　　Bjarne用了“優(yōu)雅”一詞。說得好！我MacBook上的詞典提供了如下定義：外表或舉止上令人愉悅的優(yōu)美和雅觀；令人愉悅的精致和簡單。注意對“愉悅”一詞的強調(diào)。Bjarne顯然認為整潔的代碼讀起來令人愉悅。讀這種代碼，就像見到手工精美的音樂盒或者設(shè)計精良的汽車一般，讓你會心一笑。
　　Bjarne也提到效率——而且兩次提及。這話出自C++發(fā)明者之口，或許并不出奇；不過我認為并非是在單純追求速度。被浪費掉的運算周期并不雅觀，并不令人愉悅。留意Bjarne怎么描述那種不雅觀的結(jié)果。他用了“引誘”這個詞。誠哉斯言。糟糕的代碼引發(fā)混亂！別人修改糟糕的代碼時，往往會越改越爛。
　　務(wù)實的Dave Thomas和Andy Hunt從另一角度闡述了這種情況。他們提到破窗理論4。窗戶破損了的建筑讓人覺得似乎無人照管。于是別人也再不關(guān)心。他們放任窗戶繼續(xù)破損。最終自己也參加破壞活動，在外墻上涂鴉，任垃圾堆積。一扇破損的窗戶開辟了大廈走向傾頹的道路。
　　Bjarne也提到完善錯誤處理代碼。往深處說就是在細節(jié)上花心思。敷衍了事的錯誤處理代碼只是程序員忽視細節(jié)的一種表現(xiàn)。此外還有內(nèi)存泄漏，還有競態(tài)條件代碼。還有前后不一致的命名方式。結(jié)果就是凸現(xiàn)出整潔代碼對細節(jié)的重視。
　　Bjarne以“整潔的代碼只做好一件事”結(jié)束論斷。毋庸置疑，軟件設(shè)計的許多原則最終都會歸結(jié)為這句警語。有那么多人發(fā)表過類似的言論。糟糕的代碼想做太多事，它意圖混亂、目的含混。整潔的代碼力求集中。每個函數(shù)、每個類和每個模塊都全神貫注于一事，完全不受四周細節(jié)的干擾和污染。

　　Grady Booch，Object Oriented Analysis and Design with Applications（中譯版《面向?qū)ο蠓治雠c設(shè)計》）一書作者。
　　整潔的代碼簡單直接。整潔的代碼如同優(yōu)美的散文。整潔的代碼從不隱藏設(shè)計者的意圖，充滿了干凈利落的抽象和直截了當(dāng)?shù)目刂普Z句。
　　Grady的觀點與Bjarne的觀點有類似之處，但他從可讀性的角度來定義。我特別喜歡“整潔的代碼如同優(yōu)美的散文”這種看法。想想你讀過的某本好書?；貞浺幌拢切┪淖质侨绾卧谀X中形成影像！就像是看了場電影，對吧？還不止！你還看到那些人物，聽到那些聲音，體驗到那些喜怒哀樂。
　　閱讀整潔的代碼和閱讀Lord of the Rings（中譯版《指環(huán)王》）自然不同。不過，仍有可類比之處。如同一本好的小說般，整潔的代碼應(yīng)當(dāng)明確地展現(xiàn)出要解決問題的張力。它應(yīng)當(dāng)將這種張力推至高潮，以某種顯而易見的方案解決問題和張力，使讀者發(fā)出“啊哈！本當(dāng)如此！”的感嘆。
　　竊以為Grady所謂“干凈利落的抽象”（crisp abstraction），乃是絕妙的矛盾修辭法。畢竟crisp幾乎就是“具體”（concrete）的同義詞。我MacBook上的詞典這樣定義crisp一詞：果斷決絕，就事論事，沒有猶豫或不必要的細節(jié)。盡管有兩種不同的定義，該詞還是承載了有力的信息。代碼應(yīng)當(dāng)講述事實，不引人猜測。它只該包含必需之物。讀者應(yīng)當(dāng)感受到我們的果斷決絕。

　　“老大”Dave Thomas，OTI公司創(chuàng)始人，Eclipse戰(zhàn)略教父。
　　整潔的代碼應(yīng)可由作者之外的開發(fā)者閱讀和增補。它應(yīng)當(dāng)有單元測試和驗收測試。它使用有意義的命名。它只提供一種而非多種做一件事的途徑。它只有盡量少的依賴關(guān)系，而且要明確地定義和提供清晰、盡量少的API。代碼應(yīng)通過其字面表達含義，因為不同的語言導(dǎo)致并非所有必需信息均可通過代碼自身清晰表達。
　　Dave老大在可讀性上和Grady持相同觀點，但有一個重要的不同之處。Dave斷言，整潔的代碼便于其他人加以增補。這看似顯而易見，但亦不可過分強調(diào)。畢竟易讀的代碼和易修改的代碼之間還是有區(qū)別的。
　　Dave將整潔系于測試之上！要在十年之前，這會讓人大跌眼鏡。但測試驅(qū)動開發(fā)（Test Driven Development）已在行業(yè)中造成了深遠影響，成為基礎(chǔ)規(guī)程之一。Dave說得對。沒有測試的代碼不干凈。不管它有多優(yōu)雅，不管有多可讀、多易理解，微乎測試，其不潔亦可知也。
　　Dave兩次提及“盡量少”。顯然，他推崇小塊的代碼。實際上，從有軟件起人們就在反復(fù)強調(diào)這一點。越小越好。
　　Dave也提到，代碼應(yīng)在字面上表達其含義。這一觀點源自Knuth的“字面編程”（literate programming）5。結(jié)論就是應(yīng)當(dāng)用人類可讀的方式來寫代碼。

　　Michael Feathers，Working Effectively with Legacy Code（中譯版《修改代碼的藝術(shù)》）一書作者。
　　我可以列出我留意到的整潔代碼的所有特點，但其中有一條是根本性的。整潔的代碼總是看起來像是某位特別在意它的人寫的。幾乎沒有改進的余地。代碼作者什么都想到了，如果你企圖改進它，總會回到原點，贊嘆某人留給你的代碼——全心投入的某人留下的代碼。
　　一言以蔽之：在意。這就是本書的題旨所在?；蛟S該加個副標(biāo)題，如何在意代碼。
　　Michael一針見血。整潔代碼就是作者著力照料的代碼。有人曾花時間讓它保持簡單有序。他們適當(dāng)?shù)仃P(guān)注到了細節(jié)。他們在意過。

　　Ron Jeffries，Extreme Programming Installed（中譯版《極限編程實施》）以及Extreme Programming Adventures in C#（中譯版《C#極限編程探險》）作者。
　　Ron初入行就在戰(zhàn)略空軍司令部（Strategic Air Command）編寫Fortran程序，此后幾乎在每種機器上編寫過每種語言的代碼。他的言論值得咀嚼。
　　近年來，我開始研究貝克的簡單代碼規(guī)則，差不多也都琢磨透了。簡單代碼，依其重要順序：
　　能通過所有測試；
　　沒有重復(fù)代碼；
　　體現(xiàn)系統(tǒng)中的全部設(shè)計理念；
　　包括盡量少的實體，比如類、方法、函數(shù)等。
　　在以上諸項中，我最在意代碼重復(fù)。如果同一段代碼反復(fù)出現(xiàn)，就表示某種想法未在代碼中得到良好的體現(xiàn)。我盡力去找出到底那是什么，然后再盡力更清晰地表達出來。
　　在我看來，有意義的命名是體現(xiàn)表達力的一種方式，我往往會修改好幾次才會定下名字來。借助Eclipse這樣的現(xiàn)代編碼工具，重命名代價極低，所以我無所顧忌。然而，表達力還不只體現(xiàn)在命名上。我也會檢查對象或方法是否想做的事太多。如果對象功能太多，最好是切分為兩個或多個對象。如果方法功能太多，我總是使用抽取手段（Extract Method）重構(gòu)之，從而得到一個能較為清晰地說明自身功能的方法，以及另外數(shù)個說明如何實現(xiàn)這些功能的方法。
　　消除重復(fù)和提高表達力讓我在整潔代碼方面獲益良多，只要銘記這兩點，改進臟代碼時就會大有不同。不過，我時常關(guān)注的另一規(guī)則就不太好解釋了。
　　這么多年下來，我發(fā)現(xiàn)所有程序都由極為相似的元素構(gòu)成。例如“在集合中查找某物”。不管是雇員記錄數(shù)據(jù)庫還是名-值對哈希表，或者某類條目的數(shù)組，我們都會發(fā)現(xiàn)自己想要從集合中找到某一特定條目。一旦出現(xiàn)這種情況，我通常會把實現(xiàn)手段封裝到更抽象的方法或類中。這樣做好處多多。
　　可以先用某種簡單的手段，比如哈希表來實現(xiàn)這一功能，由于對搜索功能的引用指向了我那個小小的抽象，就能隨需應(yīng)變，修改實現(xiàn)手段。這樣就既能快速前進，又能為未來的修改預(yù)留余地。
　　另外，該集合抽象常常提醒我留意“真正”在發(fā)生的事，避免隨意實現(xiàn)集合行為，因為我真正需要的不過是某種簡單的查找手段。
　　減少重復(fù)代碼，提高表達力，提早構(gòu)建簡單抽象。這就是我寫整潔代碼的方法。
　　Ron以寥寥數(shù)段文字概括了本書的全部內(nèi)容。不要重復(fù)代碼，只做一件事，表達力，小規(guī)模抽象。該有的都有了。

　　Ward Cunningham，Wiki發(fā)明者，eXtreme Programming（極限編程）的創(chuàng)始人之一，Smalltalk語言和面向?qū)ο蟮乃枷腩I(lǐng)袖。所有在意代碼者的教父。
　　如果每個例程都讓你感到深合己意，那就是整潔代碼。如果代碼讓編程語言看起來像是專為解決那個問題而存在，就可以稱之為漂亮的代碼。
　　這種說法很Ward。它教你聽了之后就點頭，然后繼續(xù)聽下去。如此在理，如此淺顯，絕不故作高深。你大概以為此言深合己意吧。再走近點看看。
　　“……深合己意”。你最近一次看到深合己意的模塊是什么時候？模塊多半都繁復(fù)難解吧？難道沒有觸犯規(guī)則嗎？你不是也曾掙扎著想抓住些從整個系統(tǒng)中散落而出的線索，編織進你在讀的那個模塊嗎？你最近一次讀到某段代碼、并且如同對Ward的說法點頭一般對這段代碼點頭，是什么時候的事了？
　　Ward期望你不會為整潔代碼所震驚。你無需花太多力氣。那代碼就是深合你意。它明確、簡單、有力。每個模塊都為下一個模塊做好準備。每個模塊都告訴你下一個模塊會是怎樣的。整潔的程序好到你根本不會注意到它。設(shè)計者把它做得像一切其他設(shè)計般簡單。
　　那Ward有關(guān)“美”的說法又如何呢？我們都曾面臨語言不是為要解決的問題所設(shè)計的困境。但Ward的說法又把球踢回我們這邊。他說，漂亮的代碼讓編程語言像是專為解決那個問題而存在！所以，讓語言變得簡單的責(zé)任就在我們身上了！當(dāng)心，語言是冥頑不化的！是程序員讓語言顯得簡單。