“这个”阴影是个好主意吗？

Question

阴影类变量的情况在Java中很常见。 Eclipse将很乐意生成这段代码：

public class TestClass {
    private int value;
    private String test;
    public TestClass(int value, String test) {
        super();
        this.value = value;
        this.test = test;
    }
    public int getValue() {
        return value;
    }
    public void setValue(int value) {
        this.value = value;
    }
    public String getTest() {
        return test;
    }
    public void setTest(String test) {
        this.test = test;
    }
}

变量阴影是否正常？

我正在考虑实施一个编码规则，说“不允许使用阴影”。 在上面的简单案例中，很明显发生了什么。 添加更多代码来执行某些操作，您可能会错过“this”并引入错误。

普遍的共识是什么？ 禁止阴影，有时允许它，或让它滚动？

Answer 1

我实际上更喜欢指南“阴影仅允许在构造函数和设置器中 ”。 其他一切都是不允许的。
为您节省命名构造函数参数aValue和aTest以避免阴影的麻烦。

如果你正在使用eclipse，它的警告设置可以完全设置为BTW选项。

Answer 2

当使用Eclipse和IntelliJ IDEA等IDE时，我觉得使用变量阴影是安全的，它突出显示不同于局部变量的颜色的字段，并且还提供有关局部变量误用的有用警告。

Answer 3

阴影在简单代码中很有用，例如构造函数getter setter和任何类型的东西。

然而，使用描述性变量非常重要，而不是使用它

this.name = name; 试试这个this.name = newName;

此外，如果你养成包含this.的习惯this. 在你的代码中，它成为第二天性，并且在可读性方面有很大帮助

Answer 4

像Eclipse这样的好IDE会以不同的颜色和/或字体显示类的属性和方法变量。 变量阴影的Becaus可以。

Answer 5

我实际上设置了我的Eclipse安装，以便为每个不合格的变量发出警告。 forget to prefix implementation variables with this. 这确保了我忘记用this.前缀实现变量this. 。 这有效地预先解决了可能由阴影引起的任何问题。

您可以通过Preferences> Java> Compiler> Errors / Warnings >> Code Style> Unqualified access to instance field来实现。

Answer 6

我一直在做“这个”阴影。 在复杂的地方，即使它没有遮挡任何东西，使用显式的this也很有用。 从人的角度来看，它更容易区分局部变量和类变量（尽管如此，它必然是一致的问题;在这里和那里使用this一点但不是到处都是令人困惑的）。

在Python中，您甚至没有选择：普通x始终是本地的。 类成员是self.x

Answer 7

样式规则的主要理由是使代码对原始作者和需要维护它的其他人都可读。 在这种情况下，可读性是指能够在机制级别和更深层次的语义级别上轻松理解代码实际执行的操作。

一般来说，（除了构造函数和setter之外）变量隐藏往往被认为是不好的样式，因为它会导致随意的读者错误地使用本地成员来使用成员，反之亦然。 （突出显示成员名称的IDE往往会缓解这一点，但仍然很容易忽略这一区别。）并且（除了构造函数和setter之外）本地和具有相同名称的成员之间通常存在明显的语义区别，并且使用不同的名称可以最好地体现这一点。

Setter和构造函数在上面的每个方面都有点不同。 由于setter（特别是）和构造函数很简单并且风格化，因此隐藏所显示的表单不太可能导致随意的读者和混淆。 实际上，我认为只使用一个标识符，基本上相同的信息实际上可以使代码更容易阅读。

在此基础上，我会说隐藏在构造函数和设置器中是完全可以接受的。 严格坚持你应该避免隐藏在这种情境中的风格规则是（IMO）迂腐的，也许会适得其反。 它肯定与大多数Java程序员认为是正常做法的步骤不一致。

Answer 8

暗影总是很糟糕。 在你的范围之后命名你的变量（不是类型），你将省去麻烦。

Answer 9

好吧，我没有看到这个代码有任何问题。 IDE很好地帮助您减少必须编写的代码量。

Answer 10

一个有效的案例是它提供了一个有说服力的签名，因此那些维护应用程序的人可以很容易地看到在Call中传递了哪些字段。

然而，Builder模式是可维护性的更好解决方案。