1. 概要
工具 | 目的 | 检查项 |
FindBugs 检查.class | 基于Bug Patterns概念,查找javabytecode(.class文件)中的潜在bug | 主要检查bytecode中的bug patterns,如code 性能、NullPoint空指针检查、没有合理关闭资源、字符串相同判断错(==,而不是equals)等 |
PMD 检查源文件 | 检查Java源文件中的潜在问题 | 主要包括: 空try/catch/finally/switch语句块 未使用的局部变量、参数和private方法 空if/while语句 过于复杂的表达式,如不必要的if语句等 复杂类 |
CheckStyle 检查源文件 主要关注格式 | 检查Java源文件是否与代码规范相符 | 主要包括: Javadoc注释 命名规范 多余没用的Imports Size度量,如过长的方法 缺少必要的空格Whitespace 重复代码 |
【注】以上工具支持Eclipse3.3及更高版本,不支持与Leaf集成
2. FindBugs
FindBugs 大多数提示有用
2.1 FindBugs是一个开源的静态代码分析工具,基于LGPL开源协议,无需运行就能对代码进行分析的工具。不注重style及format,注重检测真正的bug及潜在的性能问题 ,尤其注意了尽可能抑制误检测(false positives)的发生。以bytecode(*.class、*.jar)为对象进行检查。除了单独动作,还可以用作Eclipse的plug-in,以及嵌入Ant作为task之一进行利用。
2.2 Findbugs自带检测器的介绍: Findbugs自带60余种Bad practice,80余种Correntness,1种Internationalization,12种Malicious code vulnerability,27种Multithreaded correntness,23种Performance,43种Dodgy。
2.3 Findbugs的一些特点:
1)FindBugs主要着眼于寻找代码中的缺陷,这就与其他类似工具有些区别了,直接操作类文件(class文件)而不是源代码。
2)FindBugs可以通过命令行、各种构建工具(如Ant、Maven等)、独立的Swing GUI或是以Eclipse和NetBeans IDE插件的方式来运行。
3)FindBugs输出结果既可以是XML的,也可以是文本形式的。
4)开发者可以通过多种方式来使用FindBugs,最常见的是在新编写模块的代码分析以及对现有代码进行更大范围的分析。
5)不注重style及format,注重检测真正的bug及潜在的性能问题,尤其注意了尽可能抑制误检测(falsepositives)的发生。
2.4 FindBugs可检测的bug pattern举例:
检测java programing中容易陷入的bug pattern,code性能最优,equals() 实现时的一般规约违反Nullpointer的参照 ,Method的返回值的check遗漏 ,初始化前field的访问,Multi-thread的正确性, 同期化处理的矛盾,无条件的wait(), Code的脆弱性 ,可以变更的静态object ,内部数列参照的return等
3. PMD
3
3.1 PMD是一个代码检查工具,它用于分析 Java 源代码,找出潜在的问题:
1)潜在的bug:空的try/catch/finally/switch语句
2)未使用的代码:未使用的局部变量、参数、私有方法等
3)可选的代码:String/StringBuffer的滥用
4)复杂的表达式:不必须的if语句、可以使用while循环完成的for循环
5)重复的代码:拷贝/粘贴代码意味着拷贝/粘贴bugs
3.2 PMD特点:
1)与其他分析工具不同的是,PMD通过静态分析获知代码错误。也就是说,在
不运行Java程序的情况下报告错误。
2)PMD附带了许多可以直接使用的规则,利用这些规则可以找出Java源程序的许
多问题
3)用户还可以自己定义规则,检查Java代码是否符合某些特定的编码规范。
3.3同时,PMD已经与JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、IntelliJIDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs集成在一起。
3.4PMD规则是可以定制的: 可用的规则并不仅限于内置规则。您可以添加新规则:可以通过编写 Java 代码并重新编译 PDM,或者更简单些,编写 XPath 表达式,它会针对每个 Java 类的抽象语法树进行处理。
3.5只使用PDM内置规则,PMD 也可以找到你代码中的一些真正问题。某些问题可能很小,但有些问题则可能很大。PMD 不可能找到每个 bug,你仍然需要做单元测试和接受测试,在查找已知 bug 时,即使是 PMD 也无法替代一个好的调试器。但是,PMD 确实可以帮助你发现未知的问题。
4. CheckStyle
4.1定义: Checkstyle是一款检查Java程序源代码样式的工具。
4.2特点:
1)它可以有效的帮助我们检视代码以便更好的遵循代码编写标准,特别适用于小组开发时彼此间的样式规范和统一。
2)Checkstyle提供了高可配置性,以便适用于各种代码规范,所以除了使用它提供的几种常见标准之外,你也可以定制自己的标准。
3)Checkstyle提供了支持大多数常见IDE的插件,大部分插件中就含有最新的Checkstyle,就不用费心再部署一份了。
4)Checkstyle可以检查代码的很多方面,从传统观点看,它主要是用来检查代码层面的,自从第三版以后,它的内部架构作了重大改变,很多其它意图的检测加了进来,现在Checkstyle可以检查像类设计的问题,重复代码,如锁的双重检查的bug模式。
4.3CheckStyle的主要流程是:
1)对Java文件进行词法语法分析,生成语法树。
2)载入配置文件(checkstyle-metadata.xml以及自定义的配置文件)register check事件。
3)按照深度优先遍历对语法树进行解析,按照注册的事件,在到达某些节点( AST ) 时进行style检查(AST,A child-Sibling Tree,是语法树中的某个节点,其类型在TokenTypes类中定义。)
4)我们所说的自定义Style的检查,就是在第二步设定的。这里牵涉到一个叫com.puppycrawl.tools.checkstyle.api.Check 的类,我们通常需要重载其中的两个函数:public int[] getDefaultTokens() 和public void visitToken(DetailAST ast). 这两个函数的含义为,在遍历语法树的过程中,每当到达getDefaultTokens函数所返回的AST类型,程序就进入visitToken进行具体的检查和分析,即,真正的分析检查过程是在visitToken中实现的。
5. 附录
4
三种Eclipse插件安装方式
5.1 使用Eclipse的菜单栏 Help ->SoftwareUpdates -> Find and install... -> search for new features... ->输入软件安装地址进行安装
5.2 下载插件文件,将其解压缩到Eclipse对应的目录中。重新启动Eclipse,如果插件不能升效,则请将eclipse\configuration\org.eclipse.update目录删除后再启动Eclipse。
5.3 links文件方式。举例说明
以veloeclipse为例,D:\Jwork\Eclipse为你的Eclipse目录
将插件放置于D:\Jwork\eclipse_plugins\veloeclipse文件夹
新建文件D:\Jwork\eclipse\links\veloeclipse.link
文件内容:path=D:\\Jwork\\eclipse_plugins\\veloeclipse。
重新启动eclipse,安装完成。
推荐第三种安装方式,这样可以把你的eclipse插件放在一个独立的目录统一管理,多个Eclipse均可以指向这个eclipse插件目录。