标签: pmd

PMD在Sun Security规则集中有一个名为ArrayIsStoredDirectly的规则:

接收数组的构造函数和方法应克隆对象并存储副本.这可以防止用户将来的更改影响内部功能.

这是他们的例子:

public class Foo {
 private String [] x;
  public void foo (String [] param) {
      // Don't do this, make a copy of the array at least
      this.x=param;
  }
}

我不认为我完全理解这条规则背后的原因.是因为传递的数组中的值可以在其他地方更改吗？传递Collection与传递数组有什么不同？

作为我的程序的常规静态分析的一部分,我想检查类可能有合理的toString()方法.可能不是每个类都实现它们,但也许没有可实例化的具体类使用它Object的实现toString().

是否有一个lint工具包来检查这个？我目前使用的是FindBugs和CheckStyle; 我还没有找到一种明显的方法来检查其中任何一种.我也在考虑将PMD添加到我的lint套件中,并且也可以在Sonar中使用它.所以我更喜欢使用工具箱中已有的工具来做,但如果我需要添加另一个工具,我会考虑它.

我正在使用PMD插件(版本4.0.2)用于Eclipse(Eclipse Kepler Java EE).我已经配置了一个命名规则:ShortVariable.

除了像"id"和之类的参数外,这种方法很好"e".我希望PMD忽略这些.所以我搜索了一种忽略某些参数的方法.我找到了这个链接(尽管它是用于phpmd)并尝试过,但我似乎无法让它工作.我的配置文件看起来像这样(XML):

<?xml version="1.0"?>
<ruleset name="My PMD ruleset"
 xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">
    <description>
        My PMD
    </description>
    <rule ref="rulesets/java/naming.xml/ShortVariable">
        <property name="exceptions" value="id" />
    </rule>
</ruleset>

当我尝试使用eclipse插件导入此规则集时,它显示没有可能导入的规则.有任何想法吗？

Apache Thrift代码生成器生成的类看起来像这样.该numCpus字段可以为空,但由于它是作为值类型保存的,因此还有另一个isSet字段来确定它是否真正设置:

public class TaskConfig extends TBase<TaskConfig, TaskConfig._Fields> {
  private boolean isSetNumCpus; // Actual implemntation is a bitfield.
  private double numCpus;

  public boolean isSetNumCpus() {
    return isSetNumCpus;
  }

  public double getNumCpus() {
    return numCpus;
  }

  public void setNumCpus(double numCpus) {
    this.numCpus = numCpus;
    this.isSetNumCpus = true;
  }

  // hashCode, equals, copy constructor, field enum etc. omitted
}

我们的样式指南更喜欢将可空值包装为Optional,以便我们不会忘记空检查.所以看到这段代码很常见:

TaskConfig task = getTaskConfigFromWire();
Optional<Double> numCpus = Optional.ofNullable(task.getNumCpus());

但这是错误的 - 多亏了自动装箱这个论点永远不会null,并且正确的调用应该是这样的:

TaskConfig task = getTaskConfigFromWire();
Optional<Double> …

定义PMD规则集时是否可以从特定规则中排除源文件？

我想做类似以下的事情:

<rule ref=rulesets/java/logging-java.xml>
  <exclude name="Ignore.java" />
</rule>

仅排除似乎支持规则名称.源文件有什么类似的东西吗？

• Java 1.7.0_40
• Gradle 1.10

我从未使用过Gradle的PMD插件,而且我在尝试向我的规则集添加规则集时遇到了麻烦build.gradle.该PMD文件并未明确什么的有效值ruleSets是.他们的例子是ruleSets = ["basic", "braces"],他们链接到"官方列表".不幸的是,没有太多可继续的事情.

我猜测部分标题以某种方式映射到有效字符串？喜欢,

• "基本(java)" - >"基本"
• "大括号(java)" - >"大括号"

但是像"空代码(java)"这样的东西呢？

这是一个有效的build.gradle例子:

apply plugin: 'java'
apply plugin: 'pmd'

pmd {
    ruleSets = [
            // The first two better work since it's right in the Javadoc...
            "basic",
            "braces",
            // This one does not work and other variations like 
            // "empty code", "emptycode", "empty-code", "empty_code" do not work.
            "emptyCode"
    ]
}
repositories { …

这是(可能对某人有用)" Bean成员应该序列化 "PMD规则,其中规定了以下内容:

如果一个类是bean,或者由bean直接或间接引用它,则需要可序列化.成员变量需要在类中标记为transient,static或者具有访问器方法.将变量标记为瞬态是最安全和最简单的修改.访问器方法应遵循Java命名约定,即对于名为foo的变量,应提供getFoo()和setFoo()访问器方法.

问题是它目前既没有检查'类是bean,也没有被bean引用'甚至检查类实现'Serializable'接口.因此,在没有访问器的情况下使用几个私有字段的简单类(即使类是最终的),您将获得Sonar标记的主要缺陷.对于大多数课程,它看起来很有趣,所以目前我肯定会停用此规则.

但我确实喜欢检查真正的bean类.是否有可能(以及如何)使用Sonar和开源分析仪的"标准集"(CheckStyle,PMD,findbugs)进行类似(但更智能)的检查？有没有其他方法可以这样做？

标准的 Spring Boot 应用程序有一些主要的方法类文件，比如SampleApplication.java，看起来像这样：

@SpringBootApplication
@RestController
public class SampleApplication {

    public static void main(final String[] args) {
        SpringApplication.run(SampleApplication.class, args);
    }

}

但是 PMD 静态分析将其标记为错误 (HideUtilityClassConstructorCheck)：

实用程序类不应具有公共或默认构造函数。

确保实用程序类（在其 API 中仅包含静态方法或字段的类）没有公共构造函数。

基本原理：实例化实用程序类没有意义。因此构造函数应该是私有的，或者（如果你想允许子类化）受保护。一个常见的错误是忘记隐藏默认构造函数。

如果您使构造函数受保护，您可能需要考虑以下构造函数实现技术来禁止实例化子类：

public class StringUtils // 不是 final 以允许子类化 { protected StringUtils() { // 防止来自子类的调用 throw new UnsupportedOperationException(); } public static int count(char c, String s) { // ... } }

为什么是这样？我应该抑制这个 PMD 错误吗？

当前，我们正在使用Java Compiler 11，并将主要工件部署到Java11。在这里没有问题。

不幸的是，我们使用的服务仅支持Java 8，因此我们针对Java 8编译了其中的一些。

我们的问题是，开发人员可能会引用Java 8在运行时不可用的方法，例如List.of()，Optional::stream等。javac版本11会将其编译为Java 8，但是在JVM版本8上执行时将引发异常。

后者很容易通过一个简单的grep语句来识别，但是后者则比较棘手，需要理解代码/ AST。

我没有检查Checkstyle，Spotbugs和PMD的文档。IntelliJ实际上非常擅长于此，但是它无法集成到我们的CI管道中。

我们得到了这个天真/简单的grep语句：

grep --recursive --extended-regexp '[ \(](List|Set|Map).of' 'our_project'

我们希望有一种准确的方法来识别不兼容的API。

我正在尝试将 PMD 插件集成到构建阶段的 pom.xml 文件。

PMD版本 3.13.0

甲骨文 JDK 14

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns="http://maven.apache.org/POM/4.0.0"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>group</groupId>
    <artifactId>artifact</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>


    <properties>
        <maven.compiler.source>14</maven.compiler.source>
        <maven.compiler.target>14</maven.compiler.target>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

        <pmd.plugin.version>3.13.0</pmd.plugin.version>
    </properties>

    <dependencies>

    </dependencies>


    <reporting>
        <plugins>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-pmd-plugin</artifactId>
            </plugin>

        </plugins>
    </reporting>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-pmd-plugin</artifactId>
                    <version>${pmd.plugin.version}</version>
                </plugin>
            </plugins>
        </pluginManagement>

        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-pmd-plugin</artifactId>
                <configuration>
                    <!-- failOnViolation is actually true by default, but can be disabled -->
                    <failOnViolation>true</failOnViolation>
                    <!-- printFailingErrors is pretty useful -->
                    <printFailingErrors>true</printFailingErrors>
                    <targetJdk>14</targetJdk>
                </configuration>
                <executions>
                    <execution>
                        <goals> …