您为Java项目使用了哪些代码分析工具？ [英] What code analysis tools do you use for your Java projects?

问题描述

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

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

我对所有类型感兴趣

• 静态代码分析工具（FindBugs，PMD和其他任何工具）


• 代码覆盖工具（Cobertura，Emma和其他任何工具）


• 任何其他基于仪器的工具


• 其他任何东西，如果我遗漏了什么

• 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

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

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.

推荐答案

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

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

CPD是PMD复制/粘贴检测器工具。在我注意到查找重复代码链接之前，我正在使用PMD一段时间 PMD网页。

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

我'我想指出这些工具有时可以超出其开箱即用的规则范围。而且不仅仅是因为它们是开源的，因此您可以重写它们。其中一些工具带有应用程序或挂钩，可以扩展它们。例如，PMD附带设计器工具，可用于创建新规则。另外，Checkstyle的 DescendantToken 检查具有允许进行大量自定义的属性。

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" tool that allows you to create new rules. Also, Checkstyle has the DescendantToken check that has properties that allow for substantial customization.

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

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

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

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

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

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 filterchains 。

第二个我所做的整合就是警告抑制。默认情况下，每个工具都支持您可以放置​​在代码中的注释或注释（或两者），以消除您要忽略的警告。但是这些各种警告抑制请求没有一致的外观，看起来有些愚蠢。当你压制警告时，你是在禁止警告，所以为什么不总是写 SuppressWarning ？

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?"

例如，PMD的默认配置会在注释中使用字符串 NOPMD 来抑制代码行上的警告生成。此外，PMD支持Java的 @SuppressWarnings 注释。我将PMD配置为使用包含 SuppressWarning（PMD。而不是 NOPMD ）的注释，以便PMD抑制看起来相似。我填写使用评论样式抑制时违反的特定规则：

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 @SuppressWarnings annotation. I configure PMD to use comments containing "SuppressWarning(PMD." instead of NOPMD so that PMD suppressions look alike. I fill in the particular rule that is violated when using the comment style suppression:

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

只有抑制警告（PMD。部分对于评论很重要，但它与PMD对 @SuppressWarning 注释的支持一致，该注释确实按名称识别个别规则违规：

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：

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:OFF and 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:

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

使用Checkstyle注释时，特定的检查违规（ HiddenField ） 显着，因为每个支票都有自己的 BEGIN / END 评论对。

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

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

FindBugs also supports warning generation suppression with a @SuppressWarnings annotation, so no further configuration is required to achieve some level of uniformity with other tools. Unfortunately, Findbugs has to support a custom @SuppressWarnings annotation because the built-in Java @SuppressWarnings annotation has a SOURCE retention 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 @SuppressWarnings annotation:

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

这些技巧使得事物在各种工具中看起来相当一致。请注意，让每个警告抑制包含字符串 SuppressWarnings 可以轻松运行简单搜索，以查找整个代码库中所有工具的所有实例。

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.

这篇关于您为Java项目使用了哪些代码分析工具？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！