对于 Java 项目，您使用哪些代码分析工具？

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

我对各种东西都感兴趣

  • 静态程序分析工具(FindBugs、 PMD 和其他)
  • 代码覆盖工具(Cobertura、 Emma 和其他)
  • 任何其他基于仪器的工具
  • 如果我遗漏了什么的话

如果可行，还要说明您使用的构建工具，以及这些工具与 IDE 和构建工具的集成情况。

如果一个工具只有一种特定的方式可用(作为一个 IDE 插件，或者，比如说，一个构建工具插件) ，那么这些信息也是值得注意的。

42068 次浏览
小开

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

我没有将它集成到 Rational Application Developer (我用来开发 J2EE 应用程序的 IDE)中，因为我喜欢在 Windows 控制台中运行 javac 时它看起来非常整洁。校对: P

小开

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

小开

我们正在使用 FindBugs 和 Checkstyle 以及 Clover for Code Coverage。

我认为有一些静态分析很重要，支持你的发展。不幸的是，这些工具的重要性还没有得到广泛的认可。

小开

我正在寻找许多答案，以学习新的工具和巩固这一知识在一个问题/线程，所以我怀疑将有一个真正的答案这个问题。

对于我自己的问题，我的回答是:

  • 寻找错误/编码的常见错误-从 maven 运行，并且很容易集成到 Eclipse 中
  • Cobertura for our coverage reports - run from maven

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

在我们的例子中，所有这些都与 Maven 1.x 集成在一起，并与 Hudson 绑定在一起，后者运行我们基于签入的构建，以及每晚和每周的其他事情。Hudson 趋势图显示了我们的 JUnit 测试、覆盖率、查找错误以及开放任务。还有一个 Hudson 插件，它可以报告我们的编译警告并绘制图表。我们还使用 Hudson 绘图插件进行了几个性能测试，这些测试使用了它们自己的性能和内存使用情况图表。

小开

在 Maven 2.x 版本和 Eclipse/RAD 7中，我们可以轻松地使用和集成以下内容:

  • 测试-JUnit/TestNG
  • 代码分析-FindBugs，PMD
  • Code coverage - Clover

此外，在我们的 Maven 版本中，我们有:

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

此外，如果您正在使用 Maven 2.x，CodeHaus 在他们的 魔咒计划中有一系列方便的 Maven 插件。

注意: 三叶草与竹 CI 服务器集成了开箱即用的功能(因为它们都是 Atlassian 产品)。还有针对 FindBugs、 PMD 和 CheckStyle 的竹子插件，但是，正如前面提到的，免费的 Hudson CI 服务器也有这些插件。

小开
最佳答案

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

CPD 是 PMD 的“复制/粘贴检测器”工具。在我注意到 PMD 网页上的 "Finding Duplicated Code" link之前，我使用 PMD 有一段时间了。

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

我将这些工具与 基于 Ant 的构建集成在一起。你可以点击链接查看我的注释配置。

除了在构建中进行简单的集成之外，我发现通过其他几种方式将工具配置为某种程度上的“集成”也很有帮助。即报警生成和报警抑制的一致性。我想将这些方面添加到这个讨论中(可能还应该有“ static-analysis”标签) : 人们是如何配置这些工具来创建“统一”解决方案的？(我已经单独问了这个问题 给你)

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

/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:

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

我的警告格式转换是通过 Ant 脚本和 Ant 过滤链完成的。

我所做的第二个“集成”是用于警告抑制。默认情况下，每个工具都支持注释或注释(或两者兼而有之) ，您可以在代码中放置这些注释或注释，以使希望忽略的警告静音。但是这些各种各样的警告抑制请求看起来并不一致，这似乎有点傻。当你压制一个警告时，你就是在压制一个警告，那么为什么不总是写“ SuppressWarning?”

例如，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 @SuppressWarning annotation which does recognize individual rule violations by name:

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

类似地，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)

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

FindBugs 还支持使用 @SuppressWarnings注释抑制警告生成，因此不需要进一步的配置来实现与其他工具的某种程度的一致性。不幸的是，Findbug 必须支持自定义的 @SuppressWarnings注释，因为内置的 Java @SuppressWarnings注释有一个 SOURCE保留策略，这个策略不够强大，不足以将注释保留在 FindBugs 需要它的类文件中。为了避免与 Java 的 @SuppressWarnings注释冲突，我完全限定了 FindBugs 警告消除:

@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.

小开

我在科博图拉那边运气不错。它是一个代码覆盖工具，可以通过您的 Ant 脚本执行，作为您正常构建的一部分，并可以集成到 Hudson 中。

小开

我使用内置在 IntelliJ IDEA 中的静态分析。完美的集成。

我使用 Intellij IDEA 内置的代码覆盖率(基于 EMMA)。

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

小开

我们的团队使用 PMD 和 Cobertura，实际上我们的项目是专门的项目，并且包含用于代码分析的插件非常简单。真正的问题是对于特定的项目你需要使用哪种分析，我的观点是你不能对每个项目使用相同的插件。

小开

我结合使用了 Cobertura，Checkstyle，(Ecl) Emma 和 Findbug。

EclEmma 是一个 太棒了 Eclipse 插件，它通过在编辑器(截图)中对 java 源代码着色来显示代码覆盖率——覆盖率是通过运行 JUnit 测试生成的。当您试图确定某个特定类中覆盖了哪些行时，或者如果您希望仅仅查看单个测试覆盖了哪些行时，这非常有用。这比生成一个报告，然后查看报告来查看哪些类的覆盖率较低要友好和有用得多。

Checkstyle 和 Findbug 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 连续体.

小开

in our project we use Sonar in front of checkstyle, pmd.... together with the CI (Bamboo, Hudson) we get also a nice history of our source quality and what directing we go. I do like Sonar, because you one central tool in the CI Stack that does it for you, and you can easy customize the rules for each project.

小开

结构101 擅长于代码分析和查找循环包依赖项。


提交答案