网上对苹果iOS7操作系统中最新暴露出的一个严重安全漏洞的讨论读起来十分有趣。如果你还没有读过Alex Langley对此的分析，那现应该读一下，写的非常好。
附带说一下，是一个TLS v1.2 SSL连接问题上的bug，签名认证没有被检查，使伪造签名成为可能。原因是代码永久的直接跳到了方法的结尾处，没有实际检查哈希结果是否正确。
是什么导致了这样一个弱者的bug？我四处看了一下，下面是网友们总结出的几个原因：
- 用C语言很难写出正确无误的程序
- 苹果公司的程序员不用心
- 编码风格中允许忽略大括号
- 苹果公司里没有正规的代码审查
- 使用了goto语句
- 使用了自动代码合并
- 没有开启编译器对死代码的警告
- 没有使用静态分析工具
- 没有好好测试
所有的这些原因看起来都像是在这个bug的产生中扮演了一定的角色。但有一个主导原因吗？
对代码的差异对比给不了多少有用的信息，在631行上的这个bug看起来怎么产生的都有可能。也许是一次代码合并错误，也许是愚蠢的拷贝/粘贴造成。
事实上，你很难，或许不可能找到一个单一的为此bug负责的原因，那我们能有什么良方？很多人说是指代码上没有用花括号包围的原因。例如Zed说：
很显然写这段Apple SSL C 代码的家伙没有读过我的C语言书：永远使用花括号！
— zedshaw (@zedshaw) February 23, 2014
这就是帕金森瑣碎定理的一个很好的例子：花费大量时间讨论无关紧要的琐事。引起这个bug的根源不是缺少花括号。有没有花括号不会成为这个多余的goto的产生的原因。
为什么我们，程序员们，总是抱怨编码风格问题，但却不重视代码审查对程序正确性的决定作用呢？虽然不好的编码风格会隐藏程序bug，但并不是编码风格产生的问题。我们太重视代码布局视觉上的问题，却故意逃避正确性问题。如果更注重正确性，绝对不可能让这种关键代码中未经测试的情况下发布。
好的编码风格并不能防止大部分的bug的产生——尽管有点作用。简单的编程语言能够减少bug的产生。代码审查的作用更大。静态分析能让你避免大量的bug。
认真的测试可以捕捉并防止很多bug的产生。这就是为什么对于关键的软件，比如cryptography
library，有100%的测试覆盖率。这种一眼就能看出来的bug绝对不会在这种软件里出现。
未经测试的加密代码是用来解密的代码。
所以说，抱怨花括号是愚蠢的做法。相反，在这种情况下花括号会让问题更难发现，花括号不是问题的根源，也不是问题的解决方案。大家找错了方向。
这标题取的~ 怎么会有没有bug的软件呢。 软件都是一直下修改 改进中不断健壮的
原文看起来有点矛盾：一直在否定代码风格（比如花括号）的不重要性，感觉更增加了正确代码风格的必要性；前文刚说到代码审核这段差异对比看不出bug所在，后面却又强调了代码审核决定性作用；然后作者的重点似乎在于完善的测试是大家都忽视的东西，但实际上这一点已经在上文网友讨论里出现过了。。
还有个翻译错误，
未经测试的加密代码是用来解密的代码。原文是
Untested cryptography code is broken cryptography code.。
应翻译为，未经测试的加密代码即是坏掉的加密代码。
显然题主在逃避问题。
就连阁下自己也承认,编程风格是会影响到bug的隐藏与否的。
那么如果说好的编程风格可以避免bug的隐藏,为什么不这样做呢?
你所说的代码审查,事实上,假如代码像粥一样,那么再牛逼的程序员也没有耐心去一一阅读——乃至于他们宁可重新写一个程序出来,也不愿意在既有的基础上做任何事。
所以?
这是一篇没有营养的文章。