继续搅浑-转国内码工的评论

我就是觉得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你再把刹车拆了
难道陪审团里没有懂编程的？