大牛眼中的好代碼是什么樣子的？
有多少程序員，就有多少定義。所以我只詢問了一些非常知名且經驗豐富的程序員。
Bjarne Stroustrup，C++語言發明者，C++ Programming Language(中譯版《C++程序設計語言》)一書作者。
我喜歡優雅和高效的代碼。代碼邏輯應當直截了當，叫缺陷難以隱藏;盡量減少依賴關系，使之便于維護;依據某種分層戰略完善錯誤處理代碼;性能調至最優，省得引誘別人做沒規矩的優化，搞出一堆混亂來。整潔的代碼只做好一件事。
Bjarne用了“優雅”一詞。說得好!我MacBook上的詞典提供了如下定義：外表或舉止上令人愉悅的優美和雅觀;令人愉悅的精致和簡單。注意對“愉悅”一詞的強調。Bjarne顯然認為整潔的代碼讀起來令人愉悅。讀這種代碼，就像見到手工精美的音樂盒或者設計精良的汽車一般，讓你會心一笑。
Bjarne也提到效率——而且兩次提及。這話出自C++發明者之口，或許并不出奇;不過我認為并非是在單純追求速度。被浪費掉的運算周期并不雅觀，并不令人愉悅。留意Bjarne怎么描述那種不雅觀的結果。他用了“引誘”這個詞。誠哉斯言。糟糕的代碼引發混亂!別人修改糟糕的代碼時，往往會越改越爛。
務實的Dave Thomas和Andy Hunt從另一角度闡述了這種情況。他們提到破窗理論[5]。窗戶破損了的建筑讓人覺得似乎無人照管。于是別人也再不關心。他們放任窗戶繼續破損。最終自己也參加破壞活動，在外墻上涂鴉，任垃圾堆積。一扇破損的窗戶開辟了大廈走向傾頹的道路。
Bjarne也提到完善錯誤處理代碼。往深處說就是在細節上花心思。敷衍了事的錯誤處理代碼只是程序員忽視細節的一種表現。此外還有內存泄漏，還有競態條件代碼。還有前后不一致的命名方式。結果就是凸現出整潔代碼對細節的重視。
Bjarne以“整潔的代碼只做好一件事”結束論斷。毋庸置疑，軟件設計的許多原則最終都會歸結為這句警語。有那么多人發表過類似的言論。糟糕的代碼想做太多事，它意圖混亂、目的含混。整潔的代碼力求集中。每個函數、每個類和每個模塊都全神貫注于一事，完全不受四周細節的干擾和污染。
Grady Booch，Object Oriented Analysis and Design with Applications(中譯版《面向對象分析與設計》)一書作者。
整潔的代碼簡單直接。整潔的代碼如同優美的散文。整潔的代碼從不隱藏設計者的意圖，充滿了干凈利落的抽象和直截了當的控制語句。
Grady的觀點與Bjarne的觀點有類似之處，但他從可讀性的角度來定義。我特別喜歡“整潔的代碼如同優美的散文”這種看法。想想你讀過的某本好書。回憶一下，那些文字是如何在腦中形成影像!就像是看了場電影，對吧?還不止!你還看到那些人物，聽到那些聲音，體驗到那些喜怒哀樂。
閱讀整潔的代碼和閱讀Lord of the Rings(中譯版《指環王》)自然不同。不過，仍有可類比之處。如同一本好的小說般，整潔的代碼應當明確地展現出要解決問題的張力。它應當將這種張力推至高潮，以某種顯而易見的方案解決問題和張力，使讀者發出“啊哈!本當如此!”的感嘆。
竊以為Grady所謂“干凈利落的抽象”(crisp abstraction)，乃是絕妙的矛盾修辭法。畢竟crisp幾乎就是“具體”(concrete)的同義詞。我MacBook上的詞典這樣定義crisp一詞：果斷決絕，就事論事，沒有猶豫或不必要的細節。盡管有兩種不同的定義，該詞還是承載了有力的信息。代碼應當講述事實，不引人猜測。它只該包含必需之物。讀者應當感受到我們的果斷決絕。
“老大”Dave Thomas，OTI公司創始人，Eclipse戰略教父。
整潔的代碼應可由作者之外的開發者閱讀和增補。它應當有單元測試和驗收測試。它使用有意義的命名。它只提供一種而非多種做一件事的途徑。它只有盡量少的依賴關系，而且要明確地定義和提供清晰、盡量少的API。代碼應通過其字面表達含義，因為不同的語言導致并非所有必需信息均可通過代碼自身清晰表達。
Dave老大在可讀性上和Grady持相同觀點，但有一個重要的不同之處。Dave斷言，整潔的代碼便于其他人加以增補。這看似顯而易見，但亦不可過分強調。畢竟易讀的代碼和易修改的代碼之間還是有區別的。
Dave將整潔系于測試之上!要在十年之前，這會讓人大跌眼鏡。但測試驅動開發(Test Driven Development)已在行業中造成了深遠影響，成為基礎規程之一。Dave說得對。沒有測試的代碼不干凈。不管它有多優雅，不管有多可讀、多易理解，微乎測試，其不潔亦可知也。
Dave兩次提及“盡量少”。顯然，他推崇小塊的代碼。實際上，從有軟件起人們就在反復強調這一點。越小越好。
Dave也提到，代碼應在字面上表達其含義。這一觀點源自Knuth的“字面編程”(literate programming)[6]。結論就是應當用人類可讀的方式來寫代碼。
Michael Feathers，Working Effectively with Legacy Code(中譯版《修改代碼的藝術》)一書作者。
我可以列出我留意到的整潔代碼的所有特點，但其中有一條是根本性的。整潔的代碼總是看起來像是某位特別在意它的人寫的。幾乎沒有改進的余地。代碼作者什么都想到了，如果你企圖改進它，總會回到原點，贊嘆某人留給你的代碼——全心投入的某人留下的代碼。
一言以蔽之：在意。這就是本書的題旨所在。或許該加個副標題，如何在意代碼。
Michael一針見血。整潔代碼就是作者著力照料的代碼。有人曾花時間讓它保持簡單有序。他們適當地關注到了細節。他們在意過。
Ron Jeffries，Extreme Programming Installed(中譯版《極限編程實施》)以及Extreme Programming Adventures in C#(中譯版《C#極限編程探險》)作者。
Ron初入行就在戰略空軍司令部(Strategic Air Command)編寫Fortran程序，此后幾乎在每種機器上編寫過每種語言的代碼。他的言論值得咀嚼。
近年來，我開始研究貝克的簡單代碼規則，差不多也都琢磨透了。簡單代碼，依其重要順序：
- 能通過所有測試;
- 沒有重復代碼;
- 體現系統中的全部設計理念;
- 包括盡量少的實體，比如類、方法、函數等。
在以上諸項中，我最在意代碼重復。如果同一段代碼反復出現，就表示某種想法未在代碼中得到良好的體現。我盡力去找出到底那是什么，然后再盡力更清晰地表達出來。
在我看來，有意義的命名是體現表達力的一種方式，我往往會修改好幾次才會定下名字來。借助Eclipse這樣的現代編碼工具，重命名代價極低，所以我無所顧忌。然而，表達力還不只體現在命名上。我也會檢查對象或方法是否想做的事太多。如果對象功能太多，最好是切分為兩個或多個對象。如果方法功能太多，我總是使用抽取手段(Extract Method)重構之，從而得到一個能較為清晰地說明自身功能的方法，以及另外數個說明如何實現這些功能的方法。
消除重復和提高表達力讓我在整潔代碼方面獲益良多，只要銘記這兩點，改進臟代碼時就會大有不同。不過，我時常關注的另一規則就不太好解釋了。
這么多年下來，我發現所有程序都由極為相似的元素構成。例如“在集合中查找某物”。不管是雇員記錄數據庫還是名-值對哈希表，或者某類條目的數組，我們都會發現自己想要從集合中找到某一特定條目。一旦出現這種情況，我通常會把實現手段封裝到更抽象的方法或類中。這樣做好處多多。
可以先用某種簡單的手段，比如哈希表來實現這一功能，由于對搜索功能的引用指向了我那個小小的抽象，就能隨需應變，修改實現手段。這樣就既能快速前進，又能為未來的修改預留余地。
另外，該集合抽象常常提醒我留意“真正”在發生的事，避免隨意實現集合行為，因為我真正需要的不過是某種簡單的查找手段。
減少重復代碼，提高表達力，提早構建簡單抽象。這就是我寫整潔代碼的方法。
Ron以寥寥數段文字概括了本書的全部內容。不要重復代碼，只做一件事，表達力，小規模抽象。該有的都有了。
Ward Cunningham，Wiki發明者，eXtreme Programming(極限編程)的創始人之一，Smalltalk語言和面向對象的思想領袖。所有在意代碼者的教父。
如果每個例程都讓你感到深合己意，那就是整潔代碼。如果代碼讓編程語言看起來像是專為解決那個問題而存在，就可以稱之為漂亮的代碼。
這種說法很Ward。它教你聽了之后就點頭，然后繼續聽下去。如此在理，如此淺顯，絕不故作高深。你大概以為此言深合己意吧。再走近點看看。
“……深合己意”。你最近一次看到深合己意的模塊是什么時候?模塊多半都繁復難解吧?難道沒有觸犯規則嗎?你不是也曾掙扎著想抓住些從整個系統中散落而出的線索，編織進你在讀的那個模塊嗎?你最近一次讀到某段代碼、并且如同對Ward的說法點頭一般對這段代碼點頭，是什么時候的事了?
Ward期望你不會為整潔代碼所震驚。你無需花太多力氣。那代碼就是深合你意。它明確、簡單、有力。每個模塊都為下一個模塊做好準備。每個模塊都告訴你下一個模塊會是怎樣的。整潔的程序好到你根本不會注意到它。設計者把它做得像一切其他設計般簡單。
那Ward有關“美”的說法又如何呢?我們都曾面臨語言不是為要解決的問題所設計的困境。但Ward的說法又把球踢回我們這邊。他說，漂亮的代碼讓編程語言像是專為解決那個問題而存在!所以，讓語言變得簡單的責任就在我們身上了!當心，語言是冥頑不化的!是程序員讓語言顯得簡單。
想知道這篇文章摘自哪里嗎?來自《代碼整潔之道》，書中還有很多非常適合程序員的經典佳句，小編在這里在羅列一些給你們，希望對程序員們有所幫助。我相信下面的摘錄一定會對你有所幫助。
1、如果程序員只是為滿足編譯器或解釋器的需要而寫代碼，就會制造麻煩。例如，因為同一作用范圍內兩樣不同的東西不能重名，你可能會隨手改掉其中一個的名稱。有時干脆以錯誤的拼寫充數，結果就是出現在更正拼寫錯誤后導致編譯器出錯的情況。
2、編碼已經太多，無謂再自找麻煩。把類型或作用域編進名稱里面，徒然增加了解碼的負擔。沒理由要求每位新人都在弄清要應付的代碼之外(那算是正常的)，還要再搞懂另一種編碼“語言”。這對于解決問題而言，純屬多余的負擔。帶編碼的名稱通常也不便發音，容易打錯。
3、Java程序員不需要類型編碼。對象是強類型的，代碼編輯環境已經先進到在編譯開始前就偵測到類型錯誤的程度!所以，如今HN和其他類型編碼形式都純屬多余。它們增加了修改變量、函數或類的名稱或類型的難度。它們增加了閱讀代碼的難度。它們制造了讓編碼系統誤導讀者的可能性。
4、程序員通常都是聰明人。聰明人有時會借腦筋急轉彎炫耀其聰明。總而言之，假使你記得r代表不包含主機名和圖式(scheme)的小寫字母版url的話，那你真是太聰明了。
聰明程序員和專業程序員之間的區別在于，專業程序員了解，明確是王道。專業程序員善用其能，編寫其他人能理解的代碼。
5、記住，只有程序員才會讀你的代碼。所以，盡管用那些計算機科學(Computer Science，CS)術語、算法名、模式名、數學術語吧。依據問題所涉領域來命名可不算是聰明的做法，因為不該讓協作者老是跑去問客戶每個名稱的含義，其實他們早該通過另一名稱了解這個概念了。
對于熟悉訪問者(VISITOR)模式的程序來說，名稱AccountVisitor富有意義。哪個程序員會不知道JobQueue的意思呢?程序員要做太多技術性工作。給這些事取個技術性的名稱，通常是最靠譜的做法。
5、寫注釋的常見動機之一是糟糕的代碼的存在。我們編寫一個模塊，發現它令人困擾、亂七八糟。我們知道，它爛透了。我們告訴自己：“喔，最好寫點注釋!”不!最好是把代碼弄干凈!
帶有少量注釋的整潔而有表達力的代碼，要比帶有大量注釋的零碎而復雜的代碼像樣得多。與其花時間編寫解釋你搞出的糟糕的代碼的注釋，不如花時間清潔那堆糟糕的代碼。
6、測試代碼和生產代碼一樣重要。它可不是二等公民。它需要被思考、被設計和被照料。它該像生產代碼一般保持整潔。如果測試不能保持整潔，你就會失去它們。沒有了測試，你就會失去保證生產代碼可擴展的一切要素。你沒看錯。正是單元測試讓你的代碼可擴展、可維護、可復用。原因很簡單。有了測試，你就不擔心對代碼的修改!沒有測試，每次修改都可能帶來缺陷。無論架構多有擴展性，無論設計劃分得有多好，沒有了測試，你就很難做改動，因為你擔憂改動會引入不可預知的缺陷。
7、讓軟件能工作和讓軟件保持整潔，是兩種截然不同的工作。我們中的大多數人腦力有限，只能更多地把精力放在讓代碼能工作上，而不是放在保持代碼有組織和整潔上。這全然正確。分而治之，其在編程行為中的重要程度等同于在程序中的重要程度。
問題是太多人在程序能工作時就以為萬事大吉了。我們沒能把思維轉向有關代碼組織和整潔的部分。我們直接轉向下一個問題，而不是回頭將臃腫的類切分為只有單一權責的去耦式單元。
與此同時，許多開發者害怕數量巨大的短小單一目的類會導致難以一目了然抓住全局。他們認為，要搞清楚一件較大工作如何完成，就得在類與類之間找來找去。
然而，有大量短小類的系統并不比有少量龐大類的系統擁有更多移動部件，其數量大致相等。問題是：你是想把工具歸置到有許多抽屜、每個抽屜中裝有定義和標記良好的組件的工具箱中呢，還是想要少數幾個能隨便把所有東西扔進去的抽屜?
每個達到一定規模的系統都會包括大量邏輯和復雜性。管理這種復雜性的首要目標就是加以組織，以便開發者知道到哪兒能找到東西，并且在某個特定時間只需要理解直接有關的復雜性。反之，擁有巨大、多目的類的系統，總是讓我們在目前并不需要了解的一大堆東西中艱難跋涉。
再強調一下：系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個權責，只有一個修改的原因，并與少數其他類一起協同達成期望的系統行為。
8、我們中的大多數人都經歷過費解代碼的糾纏。我們中的許多人自己就編寫過費解的代碼。寫出自己能理解的代碼很容易，因為在寫這些代碼時，我們正深入于要解決的問題中。代碼的其他維護者不會那么深入，也就不易理解代碼。
軟件項目的主要成本在于長期維護。為了在修改時盡量降低出現缺陷的可能性，很有必要理解系統是做什么的。當系統變得越來越復雜，開發者就需要越來越多的時間來理解它，而且也極有可能誤解。所以，代碼應當清晰地表達其作者的意圖。作者把代碼寫得越清晰，其他人花在理解代碼上的時間也就越少，從而減少缺陷，縮減維護成本。
可以通過選用好名稱來表達。我們想要聽到好類名和好函數名，而且在查看其權責時不會大吃一驚。
也可以通過保持函數和類尺寸短小來表達。短小的類和函數通常易于命名，易于編寫，易于理解。
還可以通過采用標準命名法來表達。例如，設計模式很大程度上就關乎溝通和表達。通過在實現這些模式的類的名稱中采用標準模式名，例如COMMAND或VISITOR，就能充分地向其他開發者描述你的設計。
9、編寫永遠運行的系統，與編寫運行一段時間后平靜地關閉的系統是兩碼事。
平靜關閉很難做到。常見問題與死鎖有關，線程一直等待永遠不會到來的信號。
例如，想象一個系統中有個父線程分裂出數個子線程，父線程等待所有子線程結束，然后釋放資源并關閉。如果其中一個子線程發生死鎖會怎樣?父線程將一直等待下去，而系統就永遠不能關閉。
或者，考慮一個被指示關閉的類似系統。父線程告知全體子線程放棄任務并結束。如果其中兩個子線程正以生產者/消費者模型操作會怎樣呢?假設生產者線程從父線程處接收到信號，并迅速關閉。消費者線程可能還在等待生產者線程發來消息，于是就被鎖定在無法接收到關閉信號的狀態中。它會死等生產者線程，永不結束，從而導致父線程也無法結束。
這類情形并非那么不常見。如果你要編寫涉及平靜關閉的并發代碼，請多預留一些時間搞對關閉過程。
建議：盡早考慮關閉問題，盡早令其工作正常。這會花費比你預期更多的時間。檢視既有算法，因為這可能會比想象中難得多。
10、線程代碼導致“不可能失敗的”失敗。多數開發者缺乏有關線程如何與其他代碼(可能由其他作者編寫)互動的直覺。線程代碼中的缺陷可能在一千或一百萬次執行中才會顯現一次。重復執行想要復現問題令人沮喪。所以開發者常常會將失敗歸咎于宇宙射線、硬件錯誤或其他“偶發事件”。最好假設這種偶發事件根本不存在。“偶發事件”被忽略得越久，代碼就越有可能搭建于不完善的基礎之上。
建議：不要將系統錯誤歸咎于偶發事件。
如果你很喜歡小編摘選的這些內容，還有些意猶未盡，你真的要準備一本《代碼整潔之道》放在你的床頭，每天讀一讀，真的很受用。
