作者问答 – Java 编码规范

大多数开发者都同意编写安全的代码的必要性，但往往因为项目发布的压力使他们放弃了这一追求。而另一些开发者可能仅仅是不知道从哪里开始着手。无论是哪种情况，一篇现成的规范都会帮助他们改善这种善。

InfoQ 有幸与《Java Coding Guidelines》的作者们进行了一次对话，更多地了解了他们的新书是如何帮助开发者们编写更好的代码，并且使他们有一份优秀的规范可以作为参考。

InfoQ：大多数开发者都希望能够改善他们的代码质量，提高代码安全性，但也许他们还不知道从哪里着手。还有的开发者认为这一点从理论上来说虽然非常好，但是他们正在一个遗留系统的代码库中挣扎而无能为力。在这些不同的情况下，你会对这些开发者们说些什么呢？

作者：你对这本书的使用方式很大程度上取决于你目前的工作。如果你正处于一个 Java 软件开发流程的开始阶段，你也许会打算通读一篇全书，以了解其中的规范的要旨。当系统开发的过程开始后，当你对于某些规范的应用存有疑问时，你就会回过头去重新审视这些规范。

另一方面，如果你正在维护一个现有系统，那或许只有你遇到了某些“奇怪的”问题的时候，你才会想起去重新读一篇某些规范，检查代码中是否存在某些问题，再对照规范进行检查。这是一种补救式的策略。

InfoQ：看一下本书就会发现，本书的内容分为安全、防御性编程、可靠性、编程可理解性以及程序员的常见误解。在这些内容之中，你认为哪一部分是在编程中最需要注意的呢？

作者：《Java Coding Guidelines》的主要目标是当开发者对如何正确地应用某些编程概念、构件或语言特性有些不确定的时候，帮助他们做出明智的选择。程序员的误解这一部分主要解决的问题是“最常见的误解有哪些？”编程可理解性这部分对于如何确保代码不存在歧义、易于维护这一点做了深入的讲解。而安全、防御性编程和可靠性章节逐步为读者介绍了创建健壮的系统，让它们能够从攻击或停机中立即恢复所需的知识。

InfoQ：你的这本书和《The CERT Oracle Secure Coding Standard for Java__》一书是否有什么关系呢？读者们是否应该先阅读你的规范再去阅读那本书，或是两本书可以一起读呢？

作者：《The CERT Oracle Secure Coding Standard for Java》一书为 Java 的安全编码定义了一些规则，如果你违背了这些规则，就有可能导致产生被人利用的弱点。《Java Coding Guidelines》则推荐了一些改善软件安全性和可靠性的一般性作法，而即使违背了其中的某些建议，也并不代表你的代码中就此生产了缺陷。这两本书最好是能够配合使用，它们提供了各自独立的一些指导规范，而且这两本书中的内容重复很少，甚至几乎没有。多数的规范都提供了一些应当遵循的通用编码原则，而编码标准则列举了各种应当避免的错误。《Java Coding Guidelines》也引用了《The CERT Oracle Secure Coding Standard for Java》中的内容，但它的整体依然是独立的。

InfoQ：自动进行代码扫描的工具能够在多大程度上检测出这种错误呢？有了自动化工具，是否就代表程序员不必去熟悉这些概念了呢？

作者：程序员应该熟悉《Java Coding Guidelines》中的各种概念，因为在开发阶段更容易避免在代码中产生缺陷和弱点，而如果在测试阶段，或者更糟的是在部署阶段，要找到并纠正这些问题就要难得多了。大多数现有的分析工具并不健全，并且也不完全，这意味着这些分析产生的结果有可能包含错误否定或者错误肯定。开发者必须能够判断工具的诊断结论是否代表着违背了某个原则，并且还要能够避免或消除在诊断结论中没有列举出的违背情况。CERT 创建了源代码分析实验室（SCALe）工具，它使用了多种静态分析方式对代码进行评估，以找出对安全编码规则的违背情况。许多类似这样的工具都具有不重复的功能，因此需要使用多种工具以获得更大的检验覆盖程度。但 SCALe 过程只有部分是自动化的，对诊断结果必须进行人工分析，以消除错误肯定的结论。

InfoQ：你是否注意到有些团队会专门推举出一位“安全专家”？难道不应该是整个团队都去熟悉这些安全性的内容吗？

作者：如果整个团队都能够理解安全编码的概念，那效果会好得多。每个写代码的人都需要了解如何安全地编写代码，因为编写代码的时候也是调整你的代码的最佳时机。如果团队中的某位成员受过更多安全性方面的培训，那他可以通过代码审查和安全性审计的方式将这些知识有效地推广给整个团队。开发团队必须承诺他们会编写出遵循规范的代码，他们可以将本书作为参考。开发者可以参加或关注我们在 www.securecoding.cert.org 网站所订制的编码标准，并通过 newsletter 或者是 Linked 上的安全编码论坛（Secure Coding Forum）进行讨论。

InfoQ：你是否注意到有哪些错误是开发者会重复出现的吗？

作者：某些错误会经常性地出现在 Java 中，那是因为这门语言在如何应用各种编程构件方面提供了很大的自由度。举例来说，安全编码规则中的 ERR-08-J Do not catch NullPointerException or any of its ancestors （不要捕获 NullPointerException 异常或它的任何父类）就经常被违背，因为有些开发者忽视了 Java 所提供的异常处理特性。在代码中捕获或者抛出一个过于泛用的类型经常会导致错误被忽略的结果。异常处理始终都是一个挑战，因为许多 Java 应用和 web 框架将处理异常和失败情形的责任都丢给了开发者。

CERT 为各种 Java 的软件系统对《The CERT Oracle Secure Coding Standard for Java》的遵守情况做了一些分析，在我们的记录中，最容易被违背的规则有这几条：

A. EXP01-J. Never dereference null pointers（永远不要间接引用空指针）

B. ERR01-J. Do not allow exceptions to expose sensitive information （不要让异常暴露敏感信息）

C. ERR07-J. Do not throw RuntimeException, Exception, or Throwable（不要抛出 RuntimeException、 Exception、或 Throwable 类型的异常）

D. ERR08-J. Do not catch NullPointerException or any of its ancestors（不要捕获 NullPointerException 异常或它的任何父类）

E. FIO04-J. Release resources when they are no longer needed（当不再需要某个资源的时候立即释放它）

F. ERR00-J. Do not suppress or ignore checked exceptions（不要抑制或忽略查到的异常）

关于作者

Fred Long 是 Aberystwyth 大学计算机与科学系的一位高级讲师，也是学习与教学研究协会的主任，并且是 SEI 的一位客座科学家。

Dhruv Mohindra, 是 Persistent Systems Limited 印度公司中所属于 CTO 办公室的安全性实践小组的技术领导，他为多个技术领域的信息安全进行顾问服务。

Robert C. Seacord 是 CERT 的安全编码倡议小组的管理者，他也是 CMU 学校的计算机与科学系的一名副教授。

Dean F. Sutherland 是 CERT 的高级软件安全性研究员，他曾在 Tartan 公司做过 14 年的软件工程师。

David Svoboda是 CERT 的软件安全性工程师，从 1991 年开始，他就在多个 CMU 开发项目中担任主要开发者

查看英文原文： Author Q&A: Java Coding Guidelines