您在 Java 项目中使用哪些代码分析工具?[已关闭]
您在 Java 项目中使用了哪些代码分析工具?
我对各种感兴趣
- 静态代码分析工具(FindBugs、PMD 和任何其他工具)
- 代码覆盖率工具(Cobertura,Emma和任何其他工具)
- 任何其他基于仪器的工具
- 其他任何事情,如果我错过了什么
如果适用,还要说明您使用的构建工具以及这些工具与 IDE 和构建工具的集成程度。
如果工具仅以特定方式可用(作为IDE插件,或者,例如,构建工具插件),则该信息也值得注意。
您在 Java 项目中使用了哪些代码分析工具?
我对各种感兴趣
如果适用,还要说明您使用的构建工具以及这些工具与 IDE 和构建工具的集成程度。
如果工具仅以特定方式可用(作为IDE插件,或者,例如,构建工具插件),则该信息也值得注意。
对于静态分析工具,我经常使用CPD,PMD,FindBugs和Checkstyle。
CPD 是 PMD“复制/粘贴检测器”工具。在我注意到PMD网页上的“查找重复代码”链接之前,我使用PMD了一段时间。
我想指出的是,这些工具有时可以扩展到其“开箱即用”规则集之外。不仅仅是因为它们是开源的,所以你可以重写它们。其中一些工具带有应用程序或“钩子”,允许它们进行扩展。例如,PMD附带了“设计器”工具,允许您创建新规则。此外,Checkstyle 还具有“后代令牌”检查,该检查具有允许大量自定义的属性。
我将这些工具与基于 Ant 的构建集成在一起。您可以按照链接查看我注释的配置。
除了简单地集成到构建中之外,我发现将工具配置为以其他几种方式进行“集成”是有帮助的。即报告生成和警告抑制的均匀性。我想在这次讨论中加入这些方面(可能也应该有“静态分析”标签):人们如何配置这些工具来创建“统一”的解决方案?(我在这里单独问了这个问题)
首先,对于警告报告,我转换输出,以便每个警告都具有简单的格式:
/absolute-path/filename:line-number:column-number: warning(tool-name): message
这通常被称为“Emacs 格式”,但即使您不使用 Emacs,它也是使报表同质化的合理格式。例如:
/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.
我的警告格式转换是由我的 Ant 脚本使用 Ant 过滤器链完成的。
我做的第二个“集成”是用于警告抑制。默认情况下,每个工具都支持注释或批注(或两者兼而有之),您可以将这些批注或批注放在代码中,以静音要忽略的警告。但是这些不同的警告抑制请求没有一致的外观,这似乎有些愚蠢。当你抑制警告时,你是在抑制警告,所以为什么不总是写“?”SuppressWarning
例如,PMD 的默认配置禁止在注释中使用字符串 “” 的代码行生成警告。此外,PMD支持Java的注释。我将 PMD 配置为使用包含 “” 的注释,而不是使 PMD 抑制看起来相似。我填写了使用注释样式抑制时违反的特定规则:NOPMD
@SuppressWarnings
SuppressWarning(PMD.
NOPMD
// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained
只有“”部分对于注释很重要,但它与PMD对注释的支持一致,该注释确实按名称识别单个规则违规:SuppressWarnings(PMD.
@SuppressWarning
@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended
同样,Checkstyle 禁止在注释对之间生成警告(不提供注释支持)。默认情况下,用于关闭和打开 Checkstyle 的注释分别包含字符串和 。将此配置(使用 Checkstyle 的“SuppressionCommentFilter”)更改为使用字符串 “” 和 “” 会使控件看起来更像 PMD:CHECKSTYLE:OFF
CHECKSTYLE:ON
BEGIN SuppressWarnings(CheckStyle.
END SuppressWarnings(CheckStyle.
// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)
对于 Checkstyle 注释,特定的检查冲突 () 非常重要,因为每个检查都有自己的“”注释对。HiddenField
BEGIN/END
FindBugs 还支持使用注释进行警告生成抑制,因此无需进一步配置即可与其他工具实现一定程度的一致性。不幸的是,Findbugs必须支持自定义注释,因为内置的Java注释具有保留策略,该策略不够强大,无法在FindBugs需要的类文件中保留注释。我完全限定了 FindBugs 警告抑制,以避免与 Java 的注释冲突:@SuppressWarnings
@SuppressWarnings
@SuppressWarnings
SOURCE
@SuppressWarnings
@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")
这些技术使事情在工具之间看起来相当一致。请注意,如果每个警告抑制都包含字符串 “”,则可以轻松运行简单搜索以查找整个代码库中所有工具的所有实例。SuppressWarnings
我使用Cobertura,Checkstyle,(Ecl)Emma和Findbugs的组合。
EclEmma是一个很棒的Eclipse插件,它通过在编辑器中对java源代码进行着色来显示代码覆盖率(屏幕截图) - 覆盖率是通过运行JUnit测试生成的。当您尝试确定特定类中覆盖了哪些行,或者只想查看单个测试覆盖了哪些行时,这非常有用。这比生成报告然后查看报告以查看哪些类的覆盖率低更用户友好和有用。
Checkstyle和Findbugs Eclipse插件也很有用,当您键入时,它们会在编辑器中生成警告。
Maven2具有报告插件,可与上述工具配合使用,在构建时生成报告。我们用它来获取整体项目报告,当您需要汇总数字时,这些报告更有用。这些是由我们的 CI 构建生成的,这些构建使用 Continuum 运行。