网上对苹果iOS7操作系统中最新暴露出的一个严重安全漏洞的讨论读起来十分有趣。如果你还没有读过Alex Langley对此的分析，那现应该读一下，写的非常好。

附带说一下，是一个TLS v1.2 SSL连接问题上的bug，签名认证没有被检查，使伪造签名成为可能。原因是代码永久的直接跳到了方法的结尾处，没有实际检查哈希结果是否正确。

是什么导致了这样一个弱者的bug？我四处看了一下，下面是网友们总结出的几个原因：

1,用C语言很难写出正确无误的程序
2,苹果公司的程序员不用心
3,编码风格中允许忽略大括号
4,苹果公司里没有正规的代码审查
5,使用了goto语句
6,使用了自动代码合并
7,没有开启编译器对死代码的警告
8,没有使用静态分析工具
9,没有好好测试
所有的这些原因看起来都像是在这个bug的产生中扮演了一定的角色。但有一个主导原因吗？

对代码的差异对比给不了多少有用的信息，在631行上的这个bug看起来怎么产生的都有可能。也许是一次代码合并错误，也许是愚蠢的拷贝/粘贴造成。

事实上，你很难，或许不可能找到一个单一的为此bug负责的原因，那我们能有什么良方？很多人说是指代码上没有用花括号包围的原因。例如Zed说：

很显然写这段Apple SSL C 代码的家伙没有读过我的C语言书：永远使用花括号！

这就是帕金森瑣碎定理的一个很好的例子：花费大量时间讨论无关紧要的琐事。引起这个bug的根源不是缺少花括号。有没有花括号不会成为这个多余的goto的产生的原因。

为什么我们，程序员们，总是抱怨编码风格问题，但却不重视代码审查对程序正确性的决定作用呢？虽然不好的编码风格会隐藏程序bug，但并不是编码风格产生的问题。我们太重视代码布局视觉上的问题，却故意逃避正确性问题。如果更注重正确性，绝对不可能让这种关键代码中未经测试的情况下发布。

好的编码风格并不能防止大部分的bug的产生——尽管有点作用。简单的编程语言能够减少bug的产生。代码审查的作用更大。静态分析能让你避免大量的bug。

认真的测试可以捕捉并防止很多bug的产生。这就是为什么对于关键的软件，比如cryptography
library，有100%的测试覆盖率。这种一眼就能看出来的bug绝对不会在这种软件里出现。

未经测试的加密代码是用来解密的代码。

所以说，抱怨花括号是愚蠢的做法。相反，在这种情况下花括号会让问题更难发现，花括号不是问题的根源，也不是问题的解决方案。大家找错了方向。