計算機可不管你的代碼是否好懂，雖然它看起來是能讀懂你的程序，事實上計算機是在二進制環境下運行程序的。而編寫可讀性強的語言，則有利於其他開發者讀懂你的程序。所以下這些對代碼的可讀性有着積極的影響：
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);
}
清晰。清晰是優秀代碼的基本，也是其他要素的品質保證。相對於普通機械，計算機建立更爲複雜的系統的能力要強得多。對於編程來說，最基礎的挑戰就是 減少複雜度。簡單、可讀性強、模塊化、層次、設計良好、高效、優雅，都是久經考驗達成簡練代碼的方法，這些可以有效地減少代碼的複雜度。
清晰的代碼，良好的設計，明確的目標，你必須真正地瞭解到自己在每個步驟所要做的事情，否則就會一事無成。差勁的程序，往往不是因爲編程技術水平的 問題，而是因爲沒有一個明確的目標。所以，設計是開發的關鍵，能讓保持自己的目標。如果不能寫出設計計劃，不能向其他人解釋開發目標，其實說明你連自己在 做什麼都不知道。
什麼纔是“優秀代碼”最重要的特點？顯然，就像軟件工程裏所面臨的問題一樣，是代碼的平衡性。編寫代碼時，我們總是會努力保證複雜與簡練之間的平衡：選擇折衷的方式來編寫代碼，通過不斷地測試來達成我們所期望的目標。
這樣，優秀的代碼纔會完美地達成上文中所提到的所有特質。下次寫程序或是看別人的代碼時，好好地想想這些問題吧。
