1.將常常出錯的合法的c語言代碼視爲錯誤!!!提醒本身之後該用不易出錯的形式表示!!!web
2.空語句要用NULL顯示錶示!!算法
3.不要在if或while等語句中用賦值語句函數
3.要利用原型進行檢查,而且參數要用精確的數值類型測試
4.下定決心使用lint,編寫高質量的c語言代碼spa
5.要有單個函數的測試習慣!!!設計
6.要注意將==兩邊的值反過來寫,也就是相似:6==a指針
7.要大量使用斷言,注意必定要利用斷言assert或本身實現斷言對參數進行檢查調試
8.要從程序中刪去無定義的特性或者在程序中使用斷言來檢查出無定義特性的非法使用,詳細說明不清楚的斷言日誌
9,。斷言不是用來檢查錯誤的是用來檢查非法情況的。orm
10.消除隱式假定,或利用斷言判斷其正確性
11.不要隱瞞錯誤
12.利用不一樣的算法對程序的結果進行確認
13.不要等待錯誤發生,使用初始檢查程序
14.斷言的侷限是要求調用斷言的程序代碼必須可以運行到!
15.瓶頸子系統是加入斷言的絕佳之處
16.進行差錯或使用DEBUG版本時,要消除隨機性,是錯誤可再現
17.沖掉無用的信息,以避免被錯誤地使用。對於已經釋放的系統內存,出於防止依然有指針錯誤,則將全部有用內存信息覆蓋掉在釋放!!!
18.保存一個日誌,以喚起你的注意,保存調試信息,以便進行更強的錯誤檢查
19.要有逐行代碼進行跟蹤的習慣(必定要下定決心)
20.當對代碼進行逐行跟蹤時,要密切關注數據流
21.對代碼每條路徑進行測試一邊
22.不要在正常返回之中隱藏錯誤代碼
23.在設計每個函數接口時,必定要考慮好數據的返回形式,仔細斟酌,而後選擇方便調用且不會在正常返回的結果中隱藏錯誤的形式
24.編寫功能單一的函數
25.對一個函數界面的設計要從如下方面進行考慮:1.函數的傳入參數是否合理,2.函數的返回值是否合理3.函數的調用是否方便
26.避免傳入bool參數
27.程序中要避免使用莫名其妙的數字。
28.要注意曾強函數的可讀性
29.不要容忍有錯的參數
30.使用有嚴格定義的數據類型
31.在實現某個設計的時候,必定要嚴格按照設計去實現。若是在編寫代碼時只是近似地實現所提出的要求,那就很容易出錯。
32.避免使用嵌套的「?:「運算符
33.經過最大限度地增長公共代碼的數量來使代碼差別減到最少。
34.不查優先級表,用括號
35.要注意代碼自己的簡潔
36.不能毫無必要地將不一樣類型地操做符混合使用,若是必須將不一樣類型地操做符混合使用,就用括號把它們隔離開來
37.若是你要用到的數據不是你本身全部的,那怕是臨時的,也不要對其執行寫操做。
38.爲了提升效率,向全局緩衝區或靜態緩衝傳遞數據也是很吸引人的,可是這是一條充滿風險的捷徑。倘若你寫了一個函數,用來建立只給調用函數使用的數據,
39.編寫依賴於別的程序內部處理的寄生函數不只危險,並且也是不負責任的:如果宿主函數有了更改,寄生函數也就毀壞了。
那麼就將數據返回給調用函數,或保證不意外地更改這個數據。
40.緊湊的C代碼並不能保證獲得高效的機器代碼,最重要的是可讀性!!!
41.你必須養成常常詢問怎樣編寫代碼的習慣。本書就是長期堅持詢問一些簡單問題所得的結果。
l 我怎樣才能自動檢測出錯誤?
l 我怎樣才能防止錯誤?
l 這種想法和習慣是幫助我編寫無錯代碼呢仍是妨礙了我編寫無錯代碼?
42. 決不容許一樣錯誤出現兩次