這本書真的很棒！改變了我很多的想法，也教了我很多避免錯誤的方法，其實看我們的程式碼，會發現其實很多地方有遵守這些規則，當然有些地方沒有。有些原則，我認為不需要，而有些原則我持不一樣的看法。這都值得拿來討論。
有幾點感想：
1. 不僅要有防禦機制，還要有紀錄與防止錯誤的維護機制，例如輸入函式的資料流超出預定範圍，除了得考慮是讓函式無作用，我覺得更重要的是進一步，紀錄錯誤，通常只有在使用者輸入資料方面，我們會作警告的對話框，若是資料讀錯，或程式自己計算出未預期的錯誤，通常會吃下來，不動作。但更好的作法應該是把他記錄下來，並且注意為什麼錯！c++的throw catch或許是個很好機制，應該試著建立起類似的維護機制。
2. 有範例的註解，並且注明可能誤用的狀況。
3. 逐步Trace 寫過的code，所有的分支判斷都要跑過避免，只測到單一狀況。這有另一像好處，為了少跑一次分枝測試，會試著把不需要的if去掉，或將特例集中處理，增進效率。
4. 不要寫通殺的程式，亦造成歧異的函式越容意造成bug。
5. 注意需求的語意，不要利用其他功能的特性來達到需求的目的，容易發生不要的副作用。例如將nStep+(i==j)，將true當作數字來使用。
6. 較短的程式不一定跑的比較快，KISS原則。
7. 關於態度的章節，有非常深的感慨，因為我有不少他講的缺點。49-61條每一條都是金玉良言啊！
8. 程式開發準則的優先順序，之前似乎有想過這樣的問題，有些時候我也拿捏不了那個準則應該優先，我會想兩個以上的解決方案，請俊賢替我決定，當然我也不知道他的準則是什麼，哈哈。我覺得在每個不同的開發專案，可能因為不同的需求特性，開發準則優先順序會有所變動。這在開發前，PM應給予適當的提示，講白話一點，就是你要寫的有彈性點，還是這只是暫時方案，後續維護不干我們的事或下一版就會全面更新了，這樣寫法會有很大的不一樣。通常我是覺得要做的很彈性很麻煩，我才會問到底想要作怎樣，我預設都是將來改變規格，我也可以很快的應變，但是最近我發現，之後變動處都不是我預期變動的地方XD。
以下是書中提到的各要點：
1. 啟動所有編譯器中的預警功能。
這點我就認為不需要了，適當等級除錯便可。
2. 利用lint找出那些編譯器所找不到的錯誤。
可移植性的測試，我們的系統大概沒有這樣的計畫，如果要跑也絕對改不完。
3. 有單元測試就做，不要跳過去。
我們好像沒有這樣的東西，vs2005好像有。
4. 請同時保有“偵錯版”及“發行版”。
原本就有啦！
5. 請利用assert維護巨集來確認函式引數的正確性。
這是第一個學到的重要招式，不只防禦錯誤，還要進一步標示錯誤處。或許利用C++的throw catch機制，也是不錯替代方案。得好好研究。
6. 避免讓程式產生未定義的行為，不然就在這些地方加上檢查巨集，以免有人誤用了這些未定義的結果。
防禦機制，IMMain的程式充滿這樣的漏洞。
7. 適時地加上註解，以免浪費別人的時間來看懂您的檢查巨集。
這我覺得我做的還ok，雖然有時候我也看不懂我一年前寫的註解XD。
8. 拿掉含糊的假設，否則請加上檢查巨集來檢查這些條件。
9. 利用檢查巨集找出不該在正常情況下發生的現象。
10. 防禦性的寫程式時，不要把臭蟲藏起來。
11. 利用不同的演算法來協助您確認程式的結果。
其實只要跟emdist比對就好了XD
12. 避免產生隨機行為，並且讓錯誤無所遁形。
指的是消除程式語言未定義處，如使用未初始化的記憶體。很重要！
13. 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
這常發生在誤用容器資料。
14. 程式中如果有些行為太少發生了，就強迫它多發生幾次。
其實這除錯技巧常使用。
15. 多保留一些系統資訊，有助於進行更嚴謹的除錯。
這有在做，只是好像沒啥效果XD。
16. 徹底建立子系統的檢查程序，並且盡可能地去使用它。
這對畫圖好像有用，可以用來檢查暴表資料，有空寫一個試看看。
17. 小心地設計測試條件，從各種可行的方法中慎選最好的。
這觀點很好用，用0XA3這種亂數比0x00更容易發現錯誤。
18. 致力寫出無形的，而且完整的測試。
這是一個更高的境界，書上說如何藉由程式讓不懂特例狀況的菜鳥，在寫錯後就自動發現錯誤了，看起來好神啊！
19. 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
偵錯版，要寫很多檢查code就對了。
20. 不要等到錯誤發生，才被迫去逐步追蹤程式。
很重要的一點，在寫的時候就一步一步去追蹤自己寫的code。
21. 逐步追蹤您的程式。
每條路線至少追蹤一次，這條件看起還挺嚴苛、費時的。盡力去做吧！應該可以提早找到bug。
22. 逐步追蹤程式的時候，請多注意資料的流向及內容。
23. 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
這....我想bug產生後，真的查不出來再說吧！看不懂組語，囧。
24. 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，不要將錯誤代碼跟輸出的結果一起放在返回值中。
以前從來沒發現這個要點，得多加注意。
25. 不時地檢查、並且去除函式介面裡的缺失。
26. 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
一個函式一個功能，不要寫個通殺的函式，有幾個函式我好像這樣搞過，真糟糕。
27. 清楚地定義函式的引數，不要弄得模稜兩可
先限制較嚴格的條件，有用到再放寬條件。
28. 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
29. 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
其實我覺得只是要不要再函式定義處寫引數的註解，還是要利用參數定義來更清楚表達引數的定義罷了，有蕃茄這只是多按個紐而已，我覺得沒差。只是二選一。
30. 用註解來強調函式中潛在的危機。
恩！這很重要，最好還要加上正常用的範例。
31. 利用良好定義的資料型別。
可攜性的問題，我們大該不需注意。
32. 隨時注意變數會不會產生溢位或不足位的現象。
比較少碰到，通常轉換時才會發生吧。
33. 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
對設計上語意的掌握，2.0.0有犯了這個錯誤。
34. 盡量使每一個步驟都只用一段程式來完成。
其實這段例子跟他的結論，我覺得不太搭。他想表達啥，看不懂XD。
35. 去除多餘的if。
我覺得這要有高超的技巧，這不容易啊！
36. 避免層層疊疊的使用?:運算子。
糟糕我常用XD！
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. 不要讓同一個錯誤有再次出現的機會。
有幾點感想：
1. 不僅要有防禦機制，還要有紀錄與防止錯誤的維護機制，例如輸入函式的資料流超出預定範圍，除了得考慮是讓函式無作用，我覺得更重要的是進一步，紀錄錯誤，通常只有在使用者輸入資料方面，我們會作警告的對話框，若是資料讀錯，或程式自己計算出未預期的錯誤，通常會吃下來，不動作。但更好的作法應該是把他記錄下來，並且注意為什麼錯！c++的throw catch或許是個很好機制，應該試著建立起類似的維護機制。
2. 有範例的註解，並且注明可能誤用的狀況。
3. 逐步Trace 寫過的code，所有的分支判斷都要跑過避免，只測到單一狀況。這有另一像好處，為了少跑一次分枝測試，會試著把不需要的if去掉，或將特例集中處理，增進效率。
4. 不要寫通殺的程式，亦造成歧異的函式越容意造成bug。
5. 注意需求的語意，不要利用其他功能的特性來達到需求的目的，容易發生不要的副作用。例如將nStep+(i==j)，將true當作數字來使用。
6. 較短的程式不一定跑的比較快，KISS原則。
7. 關於態度的章節，有非常深的感慨，因為我有不少他講的缺點。49-61條每一條都是金玉良言啊！
8. 程式開發準則的優先順序，之前似乎有想過這樣的問題，有些時候我也拿捏不了那個準則應該優先，我會想兩個以上的解決方案，請俊賢替我決定，當然我也不知道他的準則是什麼，哈哈。我覺得在每個不同的開發專案，可能因為不同的需求特性，開發準則優先順序會有所變動。這在開發前，PM應給予適當的提示，講白話一點，就是你要寫的有彈性點，還是這只是暫時方案，後續維護不干我們的事或下一版就會全面更新了，這樣寫法會有很大的不一樣。通常我是覺得要做的很彈性很麻煩，我才會問到底想要作怎樣，我預設都是將來改變規格，我也可以很快的應變，但是最近我發現，之後變動處都不是我預期變動的地方XD。
以下是書中提到的各要點：
1. 啟動所有編譯器中的預警功能。
這點我就認為不需要了，適當等級除錯便可。
2. 利用lint找出那些編譯器所找不到的錯誤。
可移植性的測試，我們的系統大概沒有這樣的計畫，如果要跑也絕對改不完。
3. 有單元測試就做，不要跳過去。
我們好像沒有這樣的東西，vs2005好像有。
4. 請同時保有“偵錯版”及“發行版”。
原本就有啦！
5. 請利用assert維護巨集來確認函式引數的正確性。
這是第一個學到的重要招式，不只防禦錯誤，還要進一步標示錯誤處。或許利用C++的throw catch機制，也是不錯替代方案。得好好研究。
6. 避免讓程式產生未定義的行為，不然就在這些地方加上檢查巨集，以免有人誤用了這些未定義的結果。
防禦機制，IMMain的程式充滿這樣的漏洞。
7. 適時地加上註解，以免浪費別人的時間來看懂您的檢查巨集。
這我覺得我做的還ok，雖然有時候我也看不懂我一年前寫的註解XD。
8. 拿掉含糊的假設，否則請加上檢查巨集來檢查這些條件。
9. 利用檢查巨集找出不該在正常情況下發生的現象。
10. 防禦性的寫程式時，不要把臭蟲藏起來。
11. 利用不同的演算法來協助您確認程式的結果。
其實只要跟emdist比對就好了XD
12. 避免產生隨機行為，並且讓錯誤無所遁形。
指的是消除程式語言未定義處，如使用未初始化的記憶體。很重要！
13. 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
這常發生在誤用容器資料。
14. 程式中如果有些行為太少發生了，就強迫它多發生幾次。
其實這除錯技巧常使用。
15. 多保留一些系統資訊，有助於進行更嚴謹的除錯。
這有在做，只是好像沒啥效果XD。
16. 徹底建立子系統的檢查程序，並且盡可能地去使用它。
這對畫圖好像有用，可以用來檢查暴表資料，有空寫一個試看看。
17. 小心地設計測試條件，從各種可行的方法中慎選最好的。
這觀點很好用，用0XA3這種亂數比0x00更容易發現錯誤。
18. 致力寫出無形的，而且完整的測試。
這是一個更高的境界，書上說如何藉由程式讓不懂特例狀況的菜鳥，在寫錯後就自動發現錯誤了，看起來好神啊！
19. 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
偵錯版，要寫很多檢查code就對了。
20. 不要等到錯誤發生，才被迫去逐步追蹤程式。
很重要的一點，在寫的時候就一步一步去追蹤自己寫的code。
21. 逐步追蹤您的程式。
每條路線至少追蹤一次，這條件看起還挺嚴苛、費時的。盡力去做吧！應該可以提早找到bug。
22. 逐步追蹤程式的時候，請多注意資料的流向及內容。
23. 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
這....我想bug產生後，真的查不出來再說吧！看不懂組語，囧。
24. 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，不要將錯誤代碼跟輸出的結果一起放在返回值中。
以前從來沒發現這個要點，得多加注意。
25. 不時地檢查、並且去除函式介面裡的缺失。
26. 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
一個函式一個功能，不要寫個通殺的函式，有幾個函式我好像這樣搞過，真糟糕。
27. 清楚地定義函式的引數，不要弄得模稜兩可
先限制較嚴格的條件，有用到再放寬條件。
28. 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
29. 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
其實我覺得只是要不要再函式定義處寫引數的註解，還是要利用參數定義來更清楚表達引數的定義罷了，有蕃茄這只是多按個紐而已，我覺得沒差。只是二選一。
30. 用註解來強調函式中潛在的危機。
恩！這很重要，最好還要加上正常用的範例。
31. 利用良好定義的資料型別。
可攜性的問題，我們大該不需注意。
32. 隨時注意變數會不會產生溢位或不足位的現象。
比較少碰到，通常轉換時才會發生吧。
33. 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
對設計上語意的掌握，2.0.0有犯了這個錯誤。
34. 盡量使每一個步驟都只用一段程式來完成。
其實這段例子跟他的結論，我覺得不太搭。他想表達啥，看不懂XD。
35. 去除多餘的if。
我覺得這要有高超的技巧，這不容易啊！
36. 避免層層疊疊的使用?:運算子。
糟糕我常用XD！
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. 不要讓同一個錯誤有再次出現的機會。
留言