2014年2月，安全研究人员爆出苹果公司旗下的iOS和OS X操作系统出现了严重的安全漏洞，黑客可以利用这一漏洞轻松获取用户的数据。下面的这段C语言伪代码简单描述了当时的漏洞情况。

if ((error = doSomething()) != 0)  goto fail;  goto fail;  if ((error= doMore()) != 0)  goto fail; fail:  return error;

相信你一眼就能看出来，在这段代码的第三行出现了多余的代码，导致后面的其他代码“失效”，这一低级错误也让所有的安全人员大跌眼镜。你可能会说，这开发人员真是太粗心了，是不是他复制代码的时候，多复制了一行，然后忘记删除了？

可能是这个原因，但问题的源头肯定不是粗心。有专家在看完了代码文件之后，发现相关的 Bug 代码没有正确使用缩进，也没有正确使用括号，并且其中的空格、制表符和代码注释也都不统一。

换句话说，这段代码就是所谓的“烂代码”。

工作中，对于烂代码和好代码的定义，真的是千人千面。现实环境的变化，也影响着你我对于代码“好”与“坏”的判断标准。

比如说你有没有遇到过这样的场景：当你看到一段不符合自己价值观的代码，理所当然认为写的烂，于是删掉了那段代码，用自己认为更好的方法重新写了一遍，觉得挽救了这个项目。但当对这部分业务逻辑熟悉了之后，发现所删代码中的处理方式是最恰当的。

虽然对于“什么是优秀的代码“难以形成一致看法，但多年经验，让我对代码“好”与“坏”，有一些明确的判断。下面一些最关键的要素：

如果用一句话来概括，“最适合当前现实环境的代码，才是最优秀的代码。”我会在专栏中通过案例结合我的多年经验详细阐述这句话的真正含义。

我是谁？

我是范学雷，现在是 Oracle 的主任工程师，也是 OpenJDK 和 Java 安全的评审成员。自从1998年参加工作以来，我一直跑在编程的第一线，我喜欢并且也热爱代码。2004年的时候，我就加入了 Java SE 团队，这一干就是15年，这些年，我完整经历了JDK从1.5.0到9.0的整个迭代过程，同时我自己也是OpenJDK 和 Java Security 的评审成员。

作为一个代码评审者，不是简简单单的批准或者拒绝提交的代码，而是根据自己过往的编码经验提出合理的建议，帮助代码提交者规避这些失误或者错误，编写出更优秀的代码。

代码看得多了，我对代码就有了更深的理解，比如：

• 什么样的代码更容易出问题？
• 什么样的代码会招惹麻烦？
• 什么样的代码出力不讨好？
• 什么样的代码小问题闯大祸？

对程序员也有了更多的了解，比如：

• 为什么我们不愿意写注释呢？
• 为什么代码写完就不愿意修改了呢？
• 为什么我们不愿意做测试呢？
• 为什么我们向往自由而不愿意遵守规范呢？

对我来说，审阅代码的工作是一个收获大于付出的过程。每一行代码，都体现着程序员的修为，思考问题的深度，甚至是处理问题的习惯和态度。现在我把过往20年的经验沉淀下来，通过专栏呈现给你。我希望，我能教会你下面这些东西：

1. 摒弃编码坏习惯，找到高效规范的代码编写方法。
2. 提升编程敏感度，拥有专家级编码思维和全局观。
3. 重塑代码价值观，找到最适合现实环境的代码设计逻辑。
4. 紧贴工作实际场景，明确高频代码问题的最优处理和预防方案。
5. 消除代码安全隐患，为团队交付最佳性能的代码。

专栏目录

现实工作中，你遇到过最烂的代码是啥？可以在留言区吐吐槽！