您的 Java 项目使用哪些代码分析工具？

What code analysis tools do you use for your Java projects?

提问by Joshua McKinnon

What code analysis tools do you use on your Java projects?

您在 Java 项目中使用哪些代码分析工具？

I am interested in all kinds

我对各种感兴趣

• static code analysis tools (FindBugs, PMD, and any others)
• code coverage tools (Cobertura, Emma, and any others)
• any other instrumentation-based tools
• anything else, if I'm missing something

• 静态代码分析工具（FindBugs、PMD 等）
• 代码覆盖工具（Cobertura、Emma 和任何其他工具）
• 任何其他基于仪器的工具
• 其他任何东西，如果我错过了什么

If applicable, also state what build tools you use and how well these tools integrate with both your IDEs and build tools.

如果适用，还请说明您使用的构建工具以及这些工具与您的 IDE 和构建工具的集成程度。

If a tool is only available a specific way (as an IDE plugin, or, say, a build tool plugin) that information is also worth noting.

如果某个工具仅以特定方式可用（作为 IDE 插件，或者说，构建工具插件），那么该信息也值得注意。

采纳答案by Greg Mattes

For static analysis tools I often use CPD, PMD, FindBugs, and Checkstyle.

对于静态分析工具，我经常使用 CPD、PMD、FindBugs和Checkstyle。

CPD is the PMD "Copy/Paste Detector" tool. I was using PMD for a little while before I noticed the "Finding Duplicated Code" linkon the PMD web page.

CPD 是 PMD“复制/粘贴检测器”工具。我使用PMD一会儿之前，我注意到了“查找重复的代码”链接上的PMD的网页。

I'd like to point out that these tools can sometimes be extended beyond their "out-of-the-box" set of rules. And not just because they're open source so that you can rewrite them. Some of these tools come with applications or "hooks" that allow them to be extended. For example, PMD comes with the "designer" toolthat allows you to create new rules. Also, Checkstyle has the DescendantTokencheck that has properties that allow for substantial customization.

我想指出，这些工具有时可以扩展到它们的“开箱即用”规则集之外。不仅仅是因为它们是开源的，所以你可以重写它们。其中一些工具带有允许扩展的应用程序或“钩子”。例如，PMD 带有允许您创建新规则的“设计器”工具。此外，Checkstyle 具有DescendantToken检查，该检查具有允许大量自定义的属性。

I integrate these tools with an Ant-based build. You can follow the link to see my commented configuration.

我将这些工具与基于 Ant 的构建集成。您可以点击链接查看我评论的配置。

In addition to the simple integration into the build, I find it helpful to configure the tools to be somewhat "integrated" in a couple of other ways. Namely, report generation and warning suppression uniformity. I'd like to add these aspects to this discussion (which should probably have the "static-analysis" tag also): how are folks configuring these tools to create a "unified" solution? (I've asked this question separately here)

除了简单地集成到构建中之外，我发现将工具配置为以其他几种方式有点“集成”是有帮助的。即，报告生成和警告抑制的一致性。我想将这些方面添加到这个讨论中（它可能也应该有“静态分析”标签）：人们如何配置这些工具来创建一个“统一”的解决方案？（我在这里单独问过这个问题）

First, for warning reports, I transform the output so that each warning has the simple format:

首先，对于警告报告，我转换输出，使每个警告都具有简单的格式：

/absolute-path/filename:line-number:column-number: warning(tool-name): message

This is often called the "Emacs format," but even if you aren't using Emacs, it's a reasonable format for homogenizing reports. For example:

这通常被称为“Emacs 格式”，但即使您没有使用 Emacs，它也是一种用于统一报告的合理格式。例如：

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

My warning format transformations are done by my Ant script with Ant filterchains.

我的警告格式转换是由我的 Ant 脚本和 Ant filterchains 完成的。

The second "integration" that I do is for warning suppression. By default, each tool supports comments or an annotation (or both) that you can place in your code to silence a warning that you want to ignore. But these various warning suppression requests do not have a consistent look which seems somewhat silly. When you're suppressing a warning, you're suppressing a warning, so why not always write "SuppressWarning?"

我做的第二个“整合”是为了抑制警告。默认情况下，每个工具都支持注释或注释（或两者），您可以将它们放置在代码中以使您想要忽略的警告静音。但是这些各种警告抑制请求没有一致的外观，这似乎有些愚蠢。当你抑制一个警告时，你抑制了一个警告，所以为什么不总是写“ SuppressWarning？”？

For example, PMD's default configuration suppresses warning generation on lines of code with the string "NOPMD" in a comment. Also, PMD supports Java's @SuppressWarningsannotation. I configure PMD to use comments containing "SuppressWarning(PMD." instead of NOPMDso that PMD suppressions look alike. I fill in the particular rule that is violated when using the comment style suppression:

例如，PMD 的默认配置禁止NOPMD在注释中带有字符串“ ”的代码行上生成警告。另外，PMD 支持 Java 的@SuppressWarnings注解。我将 PMD 配置为使用包含“ SuppressWarning(PMD.”的注释，而不是NOPMD使 PMD 抑制看起来相似。我填写了使用注释样式抑制时违反的特定规则：

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Only the "SuppressWarnings(PMD." part is significant for a comment, but it is consistent with PMD's support for the @SuppressWarningannotation which does recognize individual rule violations by name:

只有 " SuppressWarnings(PMD." 部分对注释很重要，但它与 PMD 对@SuppressWarning通过名称识别个别规则违规的注释的支持一致：

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Similarly, Checkstyle suppresses warning generation between pairs of comments (no annotation support is provided). By default, comments to turn Checkstyle off and on contain the strings CHECKSTYLE:OFFand CHECKSTYLE:ON, respectively. Changing this configuration (with Checkstyle's "SuppressionCommentFilter") to use the strings "BEGIN SuppressWarnings(CheckStyle." and "END SuppressWarnings(CheckStyle." makes the controls look more like PMD:

类似地，Checkstyle 禁止在评论对之间生成警告（不提供注释支持）。默认情况下，关闭和打开 Checkstyle 的注释分别包含字符串CHECKSTYLE:OFF和CHECKSTYLE:ON。更改此配置（使用 Checkstyle 的“SuppressionCommentFilter”）以使用字符串“ BEGIN SuppressWarnings(CheckStyle.”和“ END SuppressWarnings(CheckStyle.”使控件看起来更像 PMD：

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

With Checkstyle comments, the particular check violation (HiddenField) issignificant because each check has its own "BEGIN/END" comment pair.

对于 Checkstyle 注释，特定的检查违规 ( HiddenField)很重要，因为每个检查都有自己的“ BEGIN/END” 注释对。

FindBugs also supports warning generation suppression with a @SuppressWarningsannotation, so no further configuration is required to achieve some level of uniformity with other tools. Unfortunately, Findbugs has to support a custom @SuppressWarningsannotation because the built-in Java @SuppressWarningsannotation has a SOURCEretention policy which is not strong enough to retain the annotation in the class file where FindBugs needs it. I fully qualify FindBugs warnings suppressions to avoid clashing with Java's @SuppressWarningsannotation:

FindBugs 还支持带@SuppressWarnings注释的警告生成抑制，因此无需进一步配置即可与其他工具实现某种程度的统一。不幸的是，FindBugs 必须支持自定义@SuppressWarnings注释，因为内置的 Java@SuppressWarnings注释具有SOURCE保留策略，该策略不够强大，无法在 FindBugs 需要的类文件中保留注释。我完全限定 FindBugs 警告抑制以避免与 Java 的@SuppressWarnings注释发生冲突：

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

These techniques makes things look reasonably consistent across tools. Note that having each warning suppression contain the string "SuppressWarnings" makes it easy to run a simple search to find all instances for all tools over an entire code base.

这些技术使工具之间看起来相当一致。请注意，让每个警告抑制都包含字符串“ SuppressWarnings”，可以轻松地运行简单的搜索来查找整个代码库中所有工具的所有实例。

回答by ggasp

We use FindBugs and JDepend integrated with Ant. We use JUnit but we're not using any coverage tool.

我们使用与 Ant 集成的 FindBugs 和 JDepend。我们使用 JUnit 但我们没有使用任何覆盖工具。

I'm not using it integrated to Rational Application Developer (the IDE I'm using to develop J2EE applications) because I like how neat it looks when you run javac in the Windows console. :P

我没有将它集成到 Rational Application Developer（我用来开发 J2EE 应用程序的 IDE）中，因为我喜欢它在 Windows 控制台中运行 javac 时的简洁外观。:P

回答by Mike Stone

Checkstyleis another one I've used at a previous company... it's mainly for style checking, but it can do some static analysis too. Also, Cloverfor code coverage, though be aware it is not a free tool.

Checkstyle是我在以前的一家公司使用过的另一个...它主要用于样式检查，但它也可以进行一些静态分析。此外，Clover用于代码覆盖，但请注意它不是免费工具。

回答by dlinsin

We are using FindBugs and Checkstyle as well as Clover for Code Coverage.

我们使用 FindBugs 和 Checkstyle 以及 Clover 进行代码覆盖。

I think it's important to have some kind of static analysis, supporting your development. Unfortunately it's still not widely spread that these tools are important.

我认为进行某种静态分析以支持您的开发很重要。不幸的是，这些工具的重要性仍未得到广泛传播。

回答by Joshua McKinnon

I am looking for many answers to learn about new tools and consolidate this knowledge in a one question/thread, so I doubt there will be 1 true answer to this question.

我正在寻找许多答案来了解新工具并将这些知识整合到一个问题/线程中，所以我怀疑这个问题会有 1 个真正的答案。

My answer to my own question is that we use:

我对自己问题的回答是，我们使用：

• Findbugs to look for common errors bad/coding - run from maven, and also integrates easily into Eclipse
• Cobertura for our coverage reports - run from maven

• Findbugs 查找常见错误错误/编码 - 从 Maven 运行，并且还可以轻松集成到 Eclipse 中
• Cobertura 用于我们的覆盖报告 - 从 maven 运行

Hudson also has a task-scanner plugin that will display a count of your TODO and FIXMEs, as well as show where they are in the source files.

Hudson 还有一个任务扫描器插件，可以显示您的 TODO 和 FIXME 的数量，并显示它们在源文件中的位置。

All are integrated with Maven 1.x in our case and tied into Hudson, which runs our builds on check-in as well as extra things nightly and weekly. Hudson trend graphs our JUnit tests, coverage, findbugs, as well as open tasks. There is also a Hudson plugin that reports and graphs our compile warnings. We also have several performance tests with their own graphs of performance and memory use over time using the Hudson plots plugin as well.

在我们的案例中，所有这些都与 Maven 1.x 集成，并与 Hudson 相关联，后者在签入时运行我们的构建以及每晚和每周的额外内容。Hudson 趋势图绘制了我们的 JUnit 测试、覆盖率、查找错误以及未完成的任务。还有一个 Hudson 插件可以报告和绘制我们的编译警告。我们还使用 Hudson plots 插件进行了一些性能测试，其中包含自己的性能和内存使用情况随时间变化的图表。

回答by Brian Laframboise

All of the following we use and integrate easiy in both our Maven 2.x builds and Eclipse/RAD 7:

我们在 Maven 2.x 构建和 Eclipse/RAD 7 中使用和集成了以下所有内容：

• Testing - JUnit/TestNG
• Code analysis - FindBugs, PMD
• Code coverage - Clover

• 测试 - JUnit/TestNG
• 代码分析 - FindBugs、PMD
• 代码覆盖率 - Clover

In addition, in our Maven builds we have:

此外，在我们的 Maven 构建中，我们有：

• JDepend
• Tag checker (TODO, FIXME, etc)

• J依赖
• 标签检查器（TODO、FIXME 等）

Furthermore, if you're using Maven 2.x, CodeHaus has a collection of handy Maven plugins in their Mojo project.

此外，如果您使用的是 Maven 2.x，CodeHaus 在他们的Mojo 项目中有一系列方便的 Maven 插件。

Note: Clover has out-of-the-box integration with the Bamboo CI server (since they're both Atlassian products). There are also Bamboo plugins for FindBugs, PMD, and CheckStyle but, as noted, the free Hudson CI server has those too.

注意：Clover 与 Bamboo CI 服务器开箱即用集成（因为它们都是 Atlassian 产品）。还有用于 FindBugs、PMD 和 CheckStyle 的 Bamboo 插件，但如前所述，免费的 Hudson CI 服务器也有这些插件。

回答by Randyaa

I've had good luck with Cobertura. It's a code coverage tool which can be executed via your ant script as part of your normal build and can be integrated into Hudson.

我在 Cobertura 上运气不错。它是一个代码覆盖工具，可以作为正常构建的一部分通过您的 ant 脚本执行，并且可以集成到 Hudson 中。

回答by Steve McLeod

I use the static analysis built into IntelliJ IDEA. Perfect integration.

我使用内置于 IntelliJ IDEA 的静态分析。完美融合。

I use the code coverage built into Intellij IDEA (based on EMMA). Again, perfect integration.

我使用内置于 Intellij IDEA（基于 EMMA）的代码覆盖率。再次，完美融合。

This integrated solution is reliable, powerful, and easy-to-use compared to piecing together tools from various vendors.

与将来自不同供应商的工具拼凑在一起相比，这种集成解决方案可靠、强大且易于使用。

回答by vaske

Our team use PMD and Cobertura, actually our projects are maven projects and there is very simple to include plug ins for code analysis. The real question would be for specific project which analysis you need to use, my opinion is that it's you couldn't use the same plugins for each project.

我们团队使用PMD和Cobertura，其实我们的项目都是maven项目，代码分析插件很简单。真正的问题是对于您需要使用哪种分析的特定项目，我的观点是您不能为每个项目使用相同的插件。

回答by Ken Liu

I use a combination of Cobertura, Checkstyle, (Ecl)Emma and Findbugs.

我使用 Cobertura、Checkstyle、(Ecl)Emma 和 Findbugs 的组合。

EclEmmais an awesomeEclipse plugin that shows the code coverage by coloring the java source in the editor (screenshot) - the coverage is generated by running a JUnit test. This is really useful when you are trying to figure out which lines are covered in a particular class, or if you want to see just which lines are covered by a single test. This is much more user friendly and useful than generating a report and then looking through the report to see which classes have low coverage.

EclEmma是一个很棒的Eclipse 插件，它通过在编辑器中为 java 源着色来显示代码覆盖率（截图）——覆盖率是通过运行 JUnit 测试生成的。当您试图找出特定类中覆盖了哪些行，或者如果您只想查看单个测试覆盖了哪些行时，这非常有用。与生成报告然后查看报告以查看哪些类的覆盖率较低相比，这更加用户友好和有用。

The Checkstyle and Findbugs Eclipse plugins are also useful, they generate warnings in the editor as you type.

Checkstyle 和 Findbugs Eclipse 插件也很有用，它们会在您键入时在编辑器中生成警告。

Maven2 has report plugins that work with the above tools to generate reports at build time. We use this to get overall project reports, which are more useful when you want aggregate numbers. These are generated by our CI builds, which run using Continuum.

Maven2 具有报告插件，可与上述工具配合使用以在构建时生成报告。我们使用它来获取整体项目报告，这在您需要汇总数字时更有用。这些是由我们的 CI 构建生成的，它们使用Continuum运行。