很多有关编程风格的建议都是为了创建高质量、可维护的代码，这很合理， 因为最容易修复 bug 的时间就是在产生 bug 之前（少量的预防措施……）。遗 憾的是，只预防往往是不够的，虽然有一些精巧的工具可以帮助您创建好的代码 ，但是很少有工具可以帮助您分析、维护或提高现有代码的质量。
写线程安全的类很难，而分析现有类的线程安全性更难，增强类使其仍然保 持线程安全也很难。以隐含假定、不变式以及预期用例（虽然在开发人员的头脑 中很清晰，但是没有以设计笔记、注释或者文档的方式记录下来）的方式编写完 类之后，人们很快就不再了解类的工作方式（或者应该如何工作），现有代码总 是比新代码难以使用。
需求：更好的代码审核工具
当然，确保高质量代码的最佳时机就是在编写代码时，因为在这个时期您最 了解它的组织方式。关于如何编写高质量代码可以找到很多建议（阅读本栏目即 可！），但是未必能从头编写所有代码或花很多时间来编写它。那么在这种情况 下该怎么办？开发人员通常喜欢重新编写代码（毕竟，与修复他人的代码或修复 自己编写但 bug 很多的代码相比，编写新代码有趣得多），但是这也是一种奢 侈，并且通常只是用今天已知的错误与明天未知的错误交换。您需要的是下面这 种工具：分析和审核现有的代码库以帮助开发人员进行代码审核并找出 bug。
我很高兴地说，随着 FindBugs 的引入，在自动代码检测和审核工具方面已 经取得重大进步。到目前为止，大多数检测工具要么极力试图证明程序是正确的 ，要么注重一些表面问题，如代码的格式编排和命名规则，最多还关注一些简单 的 bug 模式，如自赋值、未使用的域或潜在的错误（如未使用的方法参数，或 可以声明为私有或保护的方法被声明为公共的）。但是 FindBugs 不同，它利用 字节码分析和很多内置的 bug 模式检测器来查找代码中的常见 bug。它可以帮 助您找出代码的哪些位置有意或者无意地偏离了良好的设计原理。（有关 FindBugs 的介绍，请参阅 Chris Grindstaff 的文章，“ FindBugs，第 1 部 分: 提高代码质量”和“ FindBugs，第 2 部分: 编写自定义检测器”。）
设计建议和 bug 模式
对于每种 bug 模式，设计建议中都存在相应的预防要素，用于告诫我们避免 这种 bug 模式。因此如果 FindBugs 是 bug 模式检测器，那么它理所当然可以 用作审核工具，衡量代码与一组设计原理的符合程度。Java 理论与实践的很多 期文章都专门讲述设计建议的具体要素（或相应的 bug 模式）。在这一期，我 将解释 FindBugs 如何确保现有代码库遵循设计建议。让我们以新方式重复前面 的一些建议，并了解在没有遵守这些建议时，FindBugs 如何帮助检测。
关于异常的争论
在“ Java 理论与实践: 关于异常的争论”中，反对检查型异常的一个论据 是：“摸索”（也就是捕获）这种异常太容易了，并且它既不采取修正行为，也 不抛出其他异常，如清单 1 所示。在原型设计中，有时仅仅为了使程序编译， 编写空的 catch 块，目的是以后返回并填充某种错误处理策略，这时经常出现 这种“摸索”。虽然一些人提供发生这种情景的频率，是为了作为例子说明 Java 语言设计采用的异常处理方法的不易操作性，但是我认为这仅仅是错误地 使用了正确的工具。FindBugs 可以方便地检测和标记这些空的 catch 块。如果 想要忽略这种异常，可以方便地给该异常添加描述性注释，这样读者就知道您是 有意的忽略它，而不是仅仅忘了处理。
清单 1. “摸索”异常
try {
mumbleFoo();
}
catch (MumbleFooException e) {
}
哈希
在“ Java 理论与实践： 哈希”中，我略述了正确地重载 Object.equals() 和 Object.hashCode() 的基本规则，特别是相等对象（根据 equals() ） 的 hashCode() 值必须相等。虽然只要了解了这项规则，遵守起来就相当简单（并 且有些 IDE 包含一些向导，用于以一致的风格为您定义这两个方法），但是如 果重载了其中一个方法，而忘记重载另一个方法，那么通过检测很难找出 bug， 因为错误并非位于存在的代码中，而是位于不存在码中。
FindBugs 有一个检测器用于检测这个问题的很多实例，如重载了 equals() 但没有重载 hashCode() ，或重载了 hashCode() 但没有重载 equals() 。这些 检测器是 FindBugs 中最简单的，因为它们只需要检查该类中一组方法签名，并 确定是否同时重载了 equals() 和 hashCode() 。还可能错误地使用 Object 之 外的参数类型定义 equals() ；虽然这个构造是合法的，但是它的行为和您想像 的不同。Covariant Equals 检测器将检测如下有问题的重载：
public void boolean equals(Foo other) { ... }
与这个检测器相关的是 Confusing Method Names 检测器，它是对名称类似 hashcode() 和 tostring() 的方法触发的，对于下面这些类也会触发这个检测 器：具有一些只在名称大小写方面存在差异的方法，或者其方法与超类构造函数 的名称相同。虽然根据该语言的规范，这些方法名称是合法的，但是它们可能不 是您想要的。类似地，如果域 serialVersionUID 不是 final ，不是 long ， 也不是 static ，就会触发 Serialization 检测器。