C語言如何提高程序效率

好的代碼沒有一個統一的衡量標準，在程序員們的世界裏大家也是各自按照自己的標準衡量着自己和別人的代碼。不過有一個標準幾乎是被所有人認同的。服役時間越長、出錯率越高的代碼就是好代碼。所有的編程方法、代碼技巧甚至於設計模式都是為了達到這個目的而產生的。

程序的效率分兩部分：時間效率和空間效率。

時間效率 ： 指的是程序運行的速度

空間效率 ： 指的是程序佔用內存或者外存的大小

對於這兩點的把握，我們沒有明確的方法。這裏給出一些能夠達成共識的規則，大家在今後自己編碼的時候，可以通過這些規則來衡量自己的代碼是否符合要求。

　　規則1：不要一味地追求程序的效率

如果追求程序效率需要付出降低正確性、可靠性、健壯性、可讀性等質量代價，那麼可以放棄這部分效率的提高。

　　規則2：優先提高全局效率

只有整個程序的執行效率提高才有意義，把時間和精力放在某一個不常被調用的小模塊優化上得不償失。

　　規則3：針對瓶頸部分優化

在實際開發工作中，我們經常遇到一些程序執行時間過長，需要優化。有些人上來就開始逐行檢查代碼，把認為可能影響效率的地方都儘量修改一遍。這樣做不僅浪費時間，更重要的是，常常修改一遍後依然看不到明顯的效果。

這種情況下，正確的方法是先找出限制效率的“瓶頸”，在這個部分做有針對性的優化。這麼做才事半功倍。

　規則4：先優化數據結構和算法，再優化執行代碼

程序的兩大要素是算法和數據結構，它們貫穿於程序的始終。因此，對它們的優化能夠起到意想不到的良好效果。

　　規則5：時間效率和空間效率的矛盾

大多數時候，時間效率和空間效率是對立的。這就是程序設計中兩個很重要的方法論，一個是“以空間換時間”，另一個是“以時間換空間”。此時應當分析那個更重要，作出適當的折中。

早間年，硬件成本比較高，人們大多都採用以時間換空間的策略，花費一些時間，減少內存開銷。如今，內存條的價格已經非常便宜了，人們注重的是軟件的友好性，因此大部分時候都是用空間換時間。

規則6：代碼不是越短越好

很多資深程序員都會有這樣一個誤區，完成同一個功能，代碼越短越好。還經常有人説這樣的話：“就這麼個功能我幾行代碼就搞定了”。其實，追求代碼精簡是一個很大的誤區。因為精簡的代碼並不一定產生高效的機器碼。同時，它還付出了可讀性這一代價。正確的做法是適當地做到代碼精簡。

　　注意事項

1. 書寫錯誤

經常有人把“＝＝”誤寫成“＝”。“||”、“&&”、“<=”、“>=”這類符號也很容易發生少一個的錯誤。最可怕的是編譯器根本發現不了這樣的錯誤。

2. 初始化

變量（指針、數組）被創建之後應當立刻初始化，防止把未被初始化的變量當成右值使用。

3. 數值錯誤

這也是一類非常容易忽略的錯誤。變量的`初值、缺省值錯誤，或精度不夠，一旦出錯不易發現。

4. 類型轉換

為了避免數據類型轉換的錯誤，我們要儘量使用顯式的數據類型轉換，避免在編譯器中執行非我們所願的隱式數據類型轉換。

5. 溢出

溢出分兩種，一種是超過數據類型取值範圍的賦值，另一種是數組下標範圍越界。這兩種都是要時刻注意的。

7. 避免編寫技巧性很高代碼

技巧性過高的代碼一定是可讀性較差的代碼，這種代碼不易維護，後期的成本較高。

8. 好代碼要複用，壞代碼要重寫

如果原有的代碼質量比較好，儘量複用它。但是不要修補很差勁的代碼。當我們遇到差勁代碼時，最好的方法是重寫新代碼替換它。

9. 儘量使用標準庫函數

對於標準庫中有的函數，我們不要再花時間自己實現。很簡單，你自己實現的一定不比庫函數效率高。

10. 把編譯器的選擇項設置為最嚴格狀態

只有最嚴格的審查自己的代碼，才能寫出優秀的軟件產品。很多人甚至連編譯過程中出現的warning都懶得處理，這種態度堅決不能有。