Java 是否应启用RequireThis check-in Checkstyle？

内置的Checkstyle检查之一是，当您没有将

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

，您是否发现了一个严重的错误？

使用“this”调用不会阻止调用子类中重写的方法，因为它引用的是“this object”而不是“this class”。不过，它应该可以防止您将静态方法误认为是实例方法

---

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

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

---

这个。

对于编译器来说是不必要的，当IDE进行智能格式化时，用户也不需要。编写不必要的代码只是该代码中错误的一个来源（在本例中：在某些地方使用

this.

，而在其他地方不使用它）。

我肯定会关闭它。使用

this.foo（）

是非惯用Java语言，因此只应在必要时使用，以表示代码中发生了特殊情况。例如，在setter中：

void setFoo(int foo) {this.foo = foo;} void setFoo（int foo）{this.foo=foo；} 当我阅读免费使用此功能的代码时，我通常会将其标记为对面向对象编程没有严格掌握的程序员。很大程度上是因为我通常从程序员那里看到这种风格的代码，他们不明白这不是每个地方都需要的

---

坦率地说，我很惊讶在CheckStyle的库中看到了这一点。

我只会对字段启用此检查，因为我喜欢由“

this.

”在字段前面添加的额外信息。
请参阅我的（旧）问题：

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

• 很可能，几乎从未使用过关键字“

  this.

  ”，这意味着此检查将生成大量警告
• 命名覆盖（如字段和具有类似名称的方法）非常罕见，因为默认情况下，当前IDE标记代码时会有自己的警告

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

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

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

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

这是一个可能发生的输入错误，值得检查，因为如果代码失败，它可能有助于防止难以调试的问题，因为

这是因为程序中的某些内容没有设置得太晚

checkstyle设置允许您通过如下配置规则，保留对字段的这一有用检查，同时省略对方法的基本不必要检查：

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



对于方法，此规则没有实际效果，因为调用
this.getMeSomething（）
或仅调用
getMeSomething（）
对Java的方法解析没有影响。调用this.getSomethingStatic（）

在方法为静态时仍然有效这不是错误，只是各种IDE和静态分析工具中的警告。

Oops。。。忘记了问题中暗示他们行为不同的部分。。。当然，这是需要澄清的一个重要部分。像“something=something”这样的代码不应该被另一条规则捕获吗？我不知道所有的规则，但我很确定有一条“分配无效”的规则。你是对的，有一条规则会抓住这一点，使这条规则变得更不有用！似乎使用ParameterAssignment检查应该能够捕捉到任何抑制RequireThis会掩盖的问题。结合我们的力量……C#的相关问题：