Java理论与实践: 消除bug[Java编程]

很多有关编程气势的倡议都是为了成立高质量、可保护的代码,这很公道, 因为最简单修复 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 检测器.

　　以上是“Java理论与实践: 消除bug[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：