繼續攪渾-轉國內碼工的評論

我就是覺得Barr的調查思路很奇葩啊：
1、設計業餘。一個函數超過1300行代碼怎麽了，超過7k行的函數我都見過。這就一定出現Bug麽？全局變量多也一定會產生Bug麽？當然我也很討厭這種設計，但不能說明他有Bug，如果想證明的話，需要找出實質證據。
2、代碼不符合編碼規範。我又驚了，這在業內太正常了吧？估計是使用了PC-LINT或是什麽工具檢查了一下編碼規範就蹦上來，說這會產生Bug。
遞歸就一定產生Bug麽（遞歸我還真就用過一回，在後續的派生項目裏還真就出現內存分配不足死機的bug）
有的程序員會這麽寫
malloc();
while(1){
//bulabula
break;
}
free();
如果想證明不符合編碼規範，請找出證據
3、變量保護其實也是編碼規範的一種，同上。

然後Barr為了證明這些代碼的確有問題，使用了單元測試的方法
人為地改變了內存中的一個地址的值，於是出Bug了
那麽，這個Case在實際情況中真的會發生麽？

正常的路子應該是先根據用戶提供的現象以及操作步驟去嚐試再現這處Bug，（或者還有Log等），再結合代碼，逆向分析出這個Bug的原因。
或者我就單純分析代碼，分析出至少一條能夠導致出現這個Bug現象的Case，然後去再現它。
還人為地翻轉一個特定字節，你怎麽不去把用於通信的線纜都剪折了然後再測測？也能出Bug，出不了Bug你再把刹車拆了
難道陪審團裏沒有懂編程的？