寫代碼的不要耍小聰明，認認真真的敲。 代碼是給人看的，只是順便給機器去執行。 ...
什麼樣的代碼才算是好代碼。這個問題其實見仁見智，業內也沒有統一的標準可以使用。我仔細梳理了一下自己評價代碼的方法，總結了五個評價指標。
- 規模
- 執行效率
- 占用空間
- 可讀性
- 擴展性
這五個維度相互之間有著或強或弱的關聯，任意兩份代碼之間可以參考這個體系進行大概的比較，但沒有絕對的高下之分。
1. 規模
這裡的規模說的是代碼的規模，也就是解決同樣問題的程式包含的代碼行數。如果單從這個因素講，那一定是代碼規模越小越好。但規模越小往往就會讓代碼本身的複雜程度變高，影響可讀性。有個很有趣的情況，初學者和技術大牛兩種水平相差巨大的人都有對代碼規模的執念。不過他們的訴求卻是完全不同的。
1.1 初學者追求簡單
初學者評價代碼是不是簡單的最朴素的方法就是看代碼規模，他們總是覺得代碼行數越少的程式就越簡單。經常有人在微信中問為什麼我給出的解法要寫二十幾行代碼，而網上的解法卻只有十幾行。於是就讓我講一下那個十幾行的代碼。我只能說，那個十幾行的代碼來自《演算法導論》，我需要用4~5個篇幅來講，還不保證能講透徹。
在編程領域，往往簡單並不表示易懂，它可能蘊含著更高級更複雜的思想。這些對於初學者是有難度的。
for (k = 0; k < n; k++)
{
for (i = 0; i < n; i++)
{
for(j = 0; j < n; j++)
{
if (D[i][j] > D[i][k] + D[k][j])
{
D[i][j] = D[i][k] + D[k][j];
P[i][j] = P[i][k];
}
}
}這是一個計算臨接矩陣中任意兩點之間距離的一個經典演算法，叫Floyd，只有六行代碼。當年參加ACM比賽的時候就死記硬背下了這段代碼，後來一直沒有仔細研究過這個演算法的原理，目前也只是會用而已。在大部分情況下，它也不是最優的演算法。
1.2 大牛們追求省事
真正的大牛追求代碼行數少的原因一定是為了提高執行效率，但也不乏一些從業多年沒養成好習慣也被人稱為“大牛”的人仗著自己經驗豐富圖省事的一些寫法。我就見過這樣的代碼：
typedef struct _tagNode
{
int m_nID;
int m_nSN;
int m_nMode;
int m_nCode;
}Node;
Node arrNodes[100];本來應該寫這段代碼定義一個數據結構，結果被某位“大牛”寫成這樣：
int arr[100][4];九行代碼一下變成了一行，就為了少敲一些。當然，換做初學者，這樣的二維數組可能已經駕馭不了。我還見過更誇張的代碼：
int arr[100][50][30][5];寫這行代碼的人依然是個有多年工作經驗的“大牛”，這個四維數組用的風生水起。只是坑苦了後來接手他工作的同事。
這樣追求代碼規模的行為都是不可取的。
2. 執行效率
從某種意義上講，如今對程式的第一要求應該就是執行效率。人們說的最多的就是執行效率和運行空間的關係，還有執行效率和可讀性的關係。
2.1 以空間換時間
隨著硬體設備的成本越來越低，越來越多的行業都提倡以空間換時間的設計思想。一些能夠通過記錄中間數據減少計算量的地方就成了首選的優化點。
最經典的利用這個思想的演算法就是桶排序：
void main()
{
int arr[10] = {2, 5, 15, 18, 7, 10, 13, 11, 9, 0};
int arrSort[20] = { 0 };
for (int i = 0; i < 10; i++)
{
arrSort[arr[i]]++;
}
for (int i = 0; i < 20; i++)
{
if (arrSort[i] > 0)
{
printf("%d ", i);
}
}
}這段代碼通過一個空間為20的一維數組下標進行排序，空間利用是土豪級的。它的特點是排序範圍有多大，就需要一個多大的數組。
2.2 不能犧牲可讀性
底層程式員喜歡用位運算，於是常有人把簡單的計算用位運算進行優化，比如把
int a = 10;
int b = a / 2;改成
int a = 10;
int b = a >>1;由於位運算的物理特性，下麵這段代碼的確效率會更高一些。不過，很多人看到這種寫法都不一定能反應上來。
3. 占用空間
對於一些特殊的行業，比如嵌入式開發，編程過程中一定要註意的就是節省空間。因為嵌入式設備的RAM普遍比較小。這時候，桶排序的方法一定是不允許的。另外，在申請堆空間時都有嚴格的限制。
嵌入式開發中常有類似這樣的代碼：
#define NEED_MAX 800
int* p = new int[NEED_MAX];
if (p == NULL)
{
return -l;
}
delete[] p;沒有嵌入式經驗的人一定會問，這段代碼申請了一段空間後什麼也沒做就釋放掉了，這不是畫蛇添足嗎。其實，這是一段容錯代碼，就是為了保證系統中有足夠的空間供後面的代碼執行。
是不是想想就很可憐，程式運行中突然發現記憶體不夠了，不得不停掉。
4. 可讀性
對於越來越提倡代碼規範的中國軟體行業來說，可讀性開始成為不可忽視的重要因素。無論是統一的代碼風格，還是規範的命名、函數設計和註釋，這些都必須註意。
在某些公司，代碼規範被認為是評價代碼的第一要素。鐵打的項目流水的程式員，一段可讀性差的代碼對項目而言很可能意味著滅頂之災。
對於初學者，代碼規範這個要素必須非常重視，如果錯過了這個培養良好習慣的黃金時期，後面再改就很難了。
行業內有一些沿襲了很久的陋習，因為追求程式執行效率損失可讀性、為了減少代碼行數損失可讀性、為了趕工期損失可讀性甚至還有為了省事兒損失可讀性。在這些思想的驅使下，產生了很多不好的代碼習慣。
void Swap(int& a, int& b)
{
a = a ^ b;
b = a ^ b;
a = a ^ b;
}這是一個實現變數交換功能的函數，它利用了^運算的特性，完成了不藉助第三個變數進行交換的動作。有些公司的面試題甚至還會考這個。但無論從執行效率還是從輸入效率來講，它都沒有什麼優勢。也許唯一的作用就是炫技。我建議還是老老實實地這麼寫:
void Swap(int& a, int& b)
{
int t = a;
a = b;
b = t;
}在如今的編譯技術中，這段代碼已經能夠被優化到一個相當高的性能了。
再舉個例子：
g_nScore = student.GetScore() >= p->m_pNext->m_nScore ? student.GetScore() : p->m_pNext->m_nScore;這句話還是儘量寫成下麵這種形式：
if (student.GetScore() >= p->m_pNext->m_nScore)
{
g_nScore = student.GetScore();
}
else
{
g_nScore = p->m_pNext->m_nScore;
}雖然功能上沒有問題，但下麵這種寫法更有助於開發者理清自己的邏輯。
如果你仔細閱讀任意一個公司的代碼規範文檔，你都會發現它有一條最重要的指導思想，那就是為了提高代碼可讀性，允許犧牲一些其他方面的利益。
5. 擴展性
對於一些大型的、生命周期久的項目而言，擴展性相當重要。但擴展性有一個死敵就是代碼量。仔細研究一下經典的23種設計模式，沒有哪一個不是成倍地提高了代碼量。
在很多資深程式員中，還常常因為是否使用設計模式引發爭論。而這些爭論的焦點就是代碼量和擴展性這對矛盾。究竟這二者孰輕孰重呢，其實也沒有一定之規，完全取決於具體的項目情況。具體問題具體分析才是王道。
6. 初學者的權衡
對於初學者而言，究竟哪些指標應該最關註呢？我認為，當然是可讀性。
初學者學習編程時，最重要的一點就是能夠把朴素的演算法用編程語言來實現。其他的都不重要。有時，過早地追求其他四種指標會讓你誤入歧途。
面對一道題目的多種解法，你要去做選擇首先該去鑽研哪一個。是那個代碼函數最少的嗎？是那個運行時間最短的嗎？是那個開闢空間最少的嗎？還是那個擴展性最強的。這些都不是，應該是那個可讀性最好的。
可讀性好的代碼一般都不是最短的那一個，但一定是你最容易學會的。當你掌握了一個正確的解法之後，你的心裡就有了底，之後再瞭解其他解法時就更加自信，學習的動力就這樣悄悄地到來了。
很多新同學害怕代碼量大的程式，所謂的代碼量大也不過三四十行代碼，一看到就先緊張。其實，當你靜下心來以子功能為單位一點點地讀下去，你會發現它不過是幾道課後作業解法的簡單堆疊，並不難理解。相反，很多看似簡單隻有十幾行代碼的程式往往是一個大坑，一旦你扎進去，憑自己的本事根本爬不出來。
可能我說的這些很多初學者還無法明白，沒關係先記住，相信在不久的將來你完成了一定數量的練習之後，你就會明白我今天在講些什麼。
學習過程中遇到什麼問題或者想獲取學習資源的話，歡迎加入學習交流群
639368839，我們一起學C/C++！
