[Book] Writing Solid Code

程式設計的箴言──擷取自《Writing Solid Code》

1. 啟動所有編譯器中的預警功能。
2. 利用lint找出那些編譯器所找不到的錯誤。
3. 如果您有單元測試工具，請好好利用。
4. 請同時保有“偵錯版”及“上市版”。
5. 請利用assert維護巨集來確認函式引數的正確性。
6. 避免讓程式產生未定義的行為，不然就在這些地方加上維護敘述，以免有人誤用了這些未定義的結果。
7. 適時地加上註解，以免浪費別人的時間來看懂您的維護敘述。
8. 不要直接利用假設的狀況，否則請加上維護敘述來檢查這些條件。
9. 利用維護敘述找出不該在正常情況下發生的現象。
10. 不要為求包容意外的狀況而忽略了潛在的錯誤。
11. 利用不同的演算法來協助您確認程式的結果。
12. 避免產生隨機行為，並且讓錯誤無所遁形。
13. 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
14. 程式中如果有些行為太少發生了，就強迫它多發生幾次。
15. 多保留一些系統資訊，有助於進行更嚴謹的除錯。
16. 徹底建立子系統的檢查程序，並且盡可能地去使用它。
17. 小心地設計測試條件，從各種可行的方法中慎選最好的。
18. 致力寫出無形的，而且完整的測試。
19. 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
20. 不要等到錯誤發生，才被迫去逐步追蹤程式。
21. 逐步追蹤您的程式。
22. 逐步追蹤程式的時候，請多注意資料的流向及內容。
23. 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
24. 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，更不要因為傳回值的設計不良而造成錯誤。
25. 不時地檢查、並且去除函式介面裡的缺失。
26. 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
27. 清楚地定義函式的引數，不要弄得模稜兩可。
28. 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
29. 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
30. 用註解來強調函式中潛在的危機。
31. 利用定義明確的資料型別。
32. 隨時注意變數會不會產生溢位或不足位的現象。
33. 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
34. 盡量使每一個步驟都只用一段程式來完成。
35. 盡量不用if敘述來處理例外的狀況。
36. 避免層層疊疊的使用?:運算子。
37. 盡量使同一類的特殊狀況只用一段程式處理──將相同的條件敘述合成一條。
38. 避免採用程式語言的危險慣例。
39. 若非必要，不要任意將不同類的運算混在一個式子裡。萬一必須將不同的運算放在一起使用，就用括號來標明運算的順序。
40. 避免呼叫會傳回錯誤碼的函式。
41. 不屬於自己的記憶體，就不要使用。
42. 不要去使用已經被我們釋放的記憶體空間。
43. 不要把用來傳輸出結果的記憶體拿來當成作業時的暫存空間。
44. 不要以 static（或整體性）的空間來傳資料。
45. 不要讓我們的函式變成“寄生蟲”。
46. 不要濫用程式語言的特性。
47. 將 Ｃ 的原始程式寫短，編譯出來的執行碼不見得就會有效率。
48. 寫程式要盡量讓一般人看懂。
49. 錯誤不會自己“跑掉”。
50. 發現錯誤立即修正，莫待將來付出更慘痛的代價。
51. 不能只是解除錯誤的表象，要除掉病因才能真正解決問題。
52. 除非為了讓軟體更成功，非修改不可。否則不要隨便“整理”程式。
53. 不要增添沒有必要的功能。
54. 任何一項功能都要付出代價。
55. 不要容許沒有必要的彈性。
56. 不要盲目地從一堆“嘗試”中去找答案；將時間用來找尋“最正確”的方法。
57. 每完成一小部份，就先回頭測試一遍。不管進度是不是落後，一定要徹底地將程式測試過。
58. 不能只靠測試小組來除錯。
59. 不要錯怪測試人員存心找麻煩。
60. 建立自己適用的優先順序，並確實地依照這個標準來做取捨。
61. 不要讓同一個錯誤有再次出現的機會。

好了，總共六十一條，終於整理出來了，希望對各位有所幫助。想要知道更詳盡內容的話，強力建議諸位直接去翻閱本書。
http://yukuan.blogspot.com/2001/01/writing-solid-code.html