編寫簡練程式碼是程式設計師的職業修養之本

計算機可不管你的程式碼是否好懂，雖然它看起來是能讀懂你的程式，事實上計算機是在二進位制環境下執行程式的。而編寫可讀性強的語言，則有利於其他開發者讀懂你的程式。所以下這些對程式碼的可讀性有著積極的影響：

1、易於理解性

2、複查性

3、錯誤率

4、Debug

5、可修改性

6、開發時間 - 上述因素的總和

7、擴充套件質量 - 上述因素的總和

編寫可讀性強的程式碼，事實上也不會花費更多的時間，至少在開發的最後階段是這樣的。可讀性強的程式碼能讓你更容易看懂自己寫了些什麼，這也是為什麼要 如此做的重要原因。而且，我們在檢視程式碼時往往會順便檢查程式碼，這樣也有利於糾正錯誤。可讀性強的程式碼在閱讀時會被修正，也更容易使別人把你的程式碼應用到 類似的程式中。

……

編寫可讀性強的程式碼是開發過程中的不二選擇。傾向花費大量時間寫程式碼，卻忽視閱讀上的便利性，本身是一種錯誤的體制。開發人員應該盡力編寫優秀的程式碼，因為這是一勞永逸這事，也不必因為糟糕的程式碼而花費更多精力。

另外，來自 MSDN END BRACKET 欄目的作者 Paul DiLascia ，也列出了優秀程式碼應有的物質：

不管你用什麼語言進行開發，所有的優秀程式碼都會展示出共有的經典品質：簡練，易於理解，模組化，層次性，設計良好，高效，優雅，並且清晰。

簡練。這意味著能用五行程式碼解決的問題，絕不用十行程式碼。這也意味著，必須花費更多的精力來保證程式碼的簡練，而不是生產令人費解的程式碼；這還意味 著，你所厭惡的事情，是連篇累牘的開放性程式碼和函式。簡練——即結構好，可執行，設計優秀——可以讓你的程式碼更易於理解，也減少了錯誤的發生。

可讀性強。正如其字，這說明你的程式碼應該更能讓其他人看懂。要做到可讀性強，就得多寫註釋，符合大眾習慣，不要自作聰明地命名變數，比如說，用 taxrate 代替 rt 。

模組化。這意味，你得像宇宙的構成一樣來開發程式。世界是由分子構成的，而這些分子又同原子，電子，核子，夸克，和連線 (如果你相信的話) 組成。類似的，優秀的程式也是由小模組建立成大的系統，而這些小模組又由更小的部分來組成。你完全可以只使用移動，插入和刪除三個簡單的應用，來編寫一個 文字編輯器。就像原子的構成方式一樣，軟體的元件也應該具有複用性。

層次性。程式得像蛋糕內部一樣層次分明。應用執行在框架之上，框架執行在系統之上，而系統又執行在硬體之上。就算是應用程式的內部，也應該有層次。 高階層訪問低階層，而且事件正好相反(向下訪問，向上返回) ，低階層不應該知道高階層在幹些什麼。事件/反饋的基本特性，就是向上發出無指向性通知。如果你的文件直接訪問了框架，那可就有危險了。模組和層次由 API 來定義，這樣就限定了各自的執行範圍。因此，設計就變得由為重要了。

設計良好。在開發程式之前，要先花些時間來設計你的程式，因為思考的代價要小於除錯。優秀的開發準則就是，花一半時間來設計。你得寫一份功能說明 (這個程式是用來幹嘛的) 和一個深層藍圖，而 API 的功能也應該整理成文。

高效。程式不但要執行快，而且要節省資源，它不能牽扯到文件，資料連線等等。程式只做它該做的事，不能胡亂地裝載和撤銷執行緒。在執行層上，你可以在 測試之後才優化程式；但是在高階層，你必須先計劃好執行過程。如果設計中要求伺服器有大批量的延遲，最好用一個 DOG ( Data Output Gate ，資料輸出門)。

優雅。和漂亮是一個概念，它難以描述卻顯而易見。優雅綜合了簡練，高效和簡明等概念，同時還能讓人感受到高貴的氣質。舉個例子，優雅就是使用表格，或者是用遞迴來編寫程式：

{ 

    return n==0 ? 1 : n * factorial(n-1);

 }

清晰。清晰是優秀程式碼的基本，也是其他要素的品質保證。相對於普通機械，計算機建立更為複雜的系統的能力要強得多。對於程式設計來說，最基礎的挑戰就是 減少複雜度。簡單、可讀性強、模組化、層次、設計良好、高效、優雅，都是久經考驗達成簡練程式碼的方法，這些可以有效地減少程式碼的複雜度。

清晰的程式碼，良好的設計，明確的目標，你必須真正地瞭解到自己在每個步驟所要做的事情，否則就會一事無成。差勁的程式，往往不是因為程式設計技術水平的 問題，而是因為沒有一個明確的目標。所以，設計是開發的關鍵，能讓保持自己的目標。如果不能寫出設計計劃，不能向其他人解釋開發目標，其實說明你連自己在 做什麼都不知道。

什麼才是“優秀程式碼”最重要的特點？顯然，就像軟體工程裡所面臨的問題一樣，是程式碼的平衡性。編寫程式碼時，我們總是會努力保證複雜與簡練之間的平衡：選擇折衷的方式來編寫程式碼，通過不斷地測試來達成我們所期望的目標。

這樣，優秀的程式碼才會完美地達成上文中所提到的所有特質。下次寫程式或是看別人的程式碼時，好好地想想這些問題吧。