Question

其中一个内置的Checkstyle检查是RequireThis，只要你没有将this.添加到本地字段或方法调用，它就会关闭。例如，

public final class ExampleClass {
    public String getMeSomething() { 
        return "Something"; 
    }

    public String getMeSomethingElse() {
        //will violate Checkstyle; should be this.getMeSomething()
        return getMeSomething() + " else"; 
    }
}

我正在努力检查这项检查是否合理。在上面的示例中，ExampleClass是最终的，应该保证应该调用getMeSomething的“正确”版本。此外，似乎有些情况下您可能希望子类覆盖默认行为，在这种情况下，要求“this”是错误的行为。

最后，看起来过于防御性的编码行为只会使源头变得混乱，并且更难以看到实际正在进行什么。

所以，在我向我的架构师建议这是一个糟糕的启用检查之前，我想知道其他人是否已启用此检查？您是否因缺少this？

而遇到了严重错误

Answer 1

我肯定会把它关掉。使用this.foo()是非惯用Java，因此只应在必要时使用，以表示代码中发生了特殊情况。例如，在setter中：

void setFoo(int foo) {this.foo = foo;}

当我阅读无偿使用此代码的代码时，我通常将其标记为程序员而没有牢牢掌握面向对象编程。很大程度上是因为我一般都看到程序员的代码风格，他们并不了解这个不是在任何地方都需要。

我很惊讶地发现这在CheckStyle的库中是一个规则。

Answer 2

RequireThis规则确实具有有效用途，因为它可以防止方法和构造函数在应用于字段时可能出现错误。下面的代码几乎肯定是一个错误：

void setSomething(String something) {
    something = something;
}

这样的代码将编译，但除了将方法参数的值重新分配给自身之外什么都不做。作者更有可能这样做：

void setSomething(String something) {
    this.something = something;
}

这是一个可能发生的错字，值得检查，因为如果代码失败可能有助于防止难以调试的问题，因为this.something未在程序中稍后设置。

checkstyle设置允许您对字段进行此有用的检查，同时通过配置规则来省略对方法的大量不必要的检查：

   <module name="RequireThis">
       <property name="checkMethods" value="false"/>
   </module>

当涉及到方法时，此规则没有实际效果，因为调用this.getMeSomething()或仅getMeSomething()对Java的方法解析没有影响。当方法是静态时，调用this.getSomethingStatic()仍然有效，这不是错误，它只是各种IDE和静态分析工具中的警告。

Answer 3

用“这个”打电话。不会停止调用在子类中调用重写的方法，因为这指的是“此对象”而不是“此类”。它应该阻止你误解实例方法的静态方法。

说实话，这听起来不是一个特别常见的问题，我个人不认为这是值得的权衡。

Answer 4

我个人不会启用它。主要是因为每当我读取代码时，我都会在IDE中读取它（或者其他能够进行智能代码格式化的东西）。这意味着不同类型的方法调用和字段访问是根据其实际语义含义进行格式化的，而不是基于某些（可能是错误的）指示。

编译器不需要

this.，当IDE执行智能格式化时，用户也不需要。编写不必要的代码只是此代码中的错误来源（在此示例中：在某些地方使用this.而在其他地方不使用它）。

Answer 5

我只对字段启用此检查，因为我喜欢在字段前面添加“this.”的额外信息。
请参阅我的（旧）问题：Do you prefix your instance variable with ‘this’ in java ?。

但对于任何其他项目，尤其是遗留项目，我不会激活它：

可能性，关键字“this.”几乎从不使用，这意味着此检查会产生大量警告。
命名覆盖（如字段和具有类似名称的方法）非常罕见，因为当前IDE默认标记了具有自己警告的代码。

是否应启用RequireThis检查Checkstyle？

5 个答案: