1、首先我們必須要了解糟糕的代碼會導致什么問題？

• 越糟糕的代碼，別人理解的時間就越長，會導致進度嚴重滯后（代碼不僅僅是寫給自己看的，除了自己，團隊的其他成員也需要在必要的時候去理解）；
• 越糟糕的代碼，每次添加或修改代碼，如果再不改變糟糕行為的前提下，代碼回越來越爛，再也無法理清，最后會束手無策；
• 隨著混亂的增加，團隊的生產力會持續的下降，最后趨向于零。
• 當生產力下降時，管理層只會做一件事，就是增加更多的人手到項目中，期望提升生產力，可是新人并不熟悉系統的設計，但卻背負著提升生產力的可怕壓力，于是，有可能會知道出更多的混亂。

2、那什么是整潔的代碼呢？是否有一定的標準呢？

這個是沒有的，每個人都有自己整潔代碼的標準呢，我們不妨可以來看看一些非常知名且經驗豐富的程序員是怎么說的？

（1）我喜歡優雅和高效的代碼。代碼邏輯應當直截了當，叫缺陷難以隱藏；盡量減少依賴關系，使之便于維護；依據某種分層戰略完善錯誤處理代碼；性能調至最優，省得引誘別人做沒規矩的優化，搞出一堆混亂來。整潔的代碼只做好一件事。--Bjarne Stroustrup，C++語言發明者

　　（每個函數，每個類和每個模塊都全神貫注于一件事，完全不受四周細節的干擾和污染）。

（2）整潔的代碼簡單直接。整潔的代碼如同優美的散文。整潔的代碼從不隱藏設計者的意圖，充滿了干凈利落的抽象和直截了當的控制語句。--Grady Booch，Object Oriented Analysis and Design with Applications（中譯版《面向對象分析與設計》）一書作者。

?　　　　(代碼應當講述事實，不引人猜測，它只該包含必需之物。讀者應當感受到我們的果斷決絕)。

（3）整潔的代碼應可由作者之外的開發者閱讀和增補。它應當有單元測試和驗收測試。它使用有意義的命名。它只提供一種而非多種做一件事的途徑。它只有盡量少的依賴關系，而且要明確地定義和提供清晰、盡量少的API。代碼應通過其字面表達含義，因為不同的語言導致并非所有必需信息均可通過代碼自身清晰表達。 --Dave Thomas，OTI公司創始人，Eclipse戰略教父

　　（增補一詞，說明了整潔的代碼要具有可擴展性；目前而言，測試驅動開發已經在行業中有深遠影響，沒有測試的代碼是不干凈的，不管它有多優雅、多可讀、多易于理解，微于測試，其不潔亦可知道）。

（4）簡單代碼，依其重要順序：

　　　　能通過所有測試；

　　　　　　沒有重復代碼；

　　　　　　體現系統中的全部設計理念；

　　　　　　包括盡量少的實體，比如類、方法、函數等。

　　　　　　----Ron Jeffries，Extreme Programming Installed（中譯版《極限編程實施》）以及Extreme Programming Adventures in C#（中譯版《C#極限編程探險》）作者。

　　　　　　（減少重復代碼，提高表達力，提早構建簡單抽象。這就是寫整潔代碼的方法）。

　　（5）如果每個例程都讓你感到深合己意，那就是整潔代碼。如果代碼讓編程語言看起來像是專為解決那個問題而存在，就可以稱之為漂亮的代碼。--Ward Cunningham，Wiki發明者，eXtreme Programming（極限編程）的創始人之一，Smalltalk語言和面向對象的思想領袖。所有在意代碼者的教父。

　　　　　　（你可以想想最近一次看到深合己意的模塊是什么時候，其實整潔的程序好到你根本不會注意到它，設計者把它做得像一切其他設計般簡單）。

3、童子軍軍規

　　美國的童子軍有一條簡單的軍規，就是“讓營地比你來時更干凈”，這完全可以應用到我們的專業領域：代碼每次簽入時，都要比簽出時干凈才行，這樣子代碼就不會腐壞，如果不能時時刻刻的保持代碼整潔，隨著時間的流逝，代碼必將腐壞，因為不好的代碼會“代代相傳”（傳說中的破窗效應）。

轉載于:https://www.cnblogs.com/Helius/p/6392313.html

總結

以上是生活随笔為你收集整理的整洁代码系列（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。