15

The case of shadowing class variables is common in in Java. Eclipse will happily generate this code:

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;
    }
}

Is variable shadowing ever ok?

I am considering the implementation of a coding rule saying that "shadowing will not be allowed." In the simple case above it is clear enough what is going on. Add in a little more code that does something and you run the risk of missing "this" and introducing a bug.

What is the general consensus? Ban shadowing, allow it sometimes, or let it roll?

4

10 回答 10

21

I actually prefer the guideline "Shadowing is only allowed in constructors and setters". Everything else is not allowed.
Saves you the trouble of naming constructor arguments aValue and aTest just to avoid shadowing.

If you're using eclipse, its warnings settings can be set exactly to that option BTW.

于 2010-02-16T07:18:45.797 回答
3

I feel safe with variable shadowing when using IDEs such as Eclipse and IntelliJ IDEA which highlight fields in different colors than the local variables and also provide helpful warnings on local variable mis-uses.

于 2010-02-16T07:22:07.007 回答
3

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

然而，描述性变量的使用非常重要，所以不要使用这个

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

此外，如果您养成this.在代码中包含的习惯，它就会成为第二天性，并且有助于提高可读性

于 2010-02-16T07:25:27.717 回答
2

像 Eclipse 这样的优秀 IDE 会以不同的颜色和/或字体向您显示类的属性和方法变量。因为那个变量阴影是可以的。

于 2010-02-16T07:22:34.697 回答
1

我实际上设置了我的 Eclipse 安装，为每个不合格的变量发出警告。这确保我永远不会忘记在实现变量前面加上this.. 这有效地先发制人地解决了阴影可能引起的任何问题。

您可以通过 Preferences > Java > Compiler > Errors/Warnings >> Code Style > Unqualified access to instance field 来做到这一点。

于 2010-02-16T07:25:27.693 回答
1

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

在 Python 中，你甚至没有选择：plainx总是本地的。班级成员是self.x。

于 2010-02-16T07:28:42.383 回答
1

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

通常，（除了构造函数和设置器）变量隐藏往往被认为是不好的风格，因为它会导致不经意的读者误认为使用局部变量是使用成员，反之亦然。（突出成员名称的 IDE 往往会减轻这种情况，但仍然很容易忽略这种区别。）并且（除了构造函数和设置器）本地和具有相同名称的成员之间通常存在明显的语义区别，并且这最好通过使用不同的名称来反映。

设置器和构造器在上述每个方面都有点不同。由于设置器（特别是）和构造器是简单且风格化的，所以显示的表单的隐藏不太可能引起不经意的读者和混淆。事实上，我认为只使用一个标识符来表示本质上相同的信息实际上可能会使代码更易于阅读。

在此基础上，我会说隐藏在构造函数和设置器中是完全可以接受的。严格要求您应该避免隐藏在这种情况下的风格规则是（IMO）迂腐并且可能适得其反。而且这肯定与大多数 Java 编码人员认为的正常做法不符。

于 2010-02-16T11:01:19.563 回答
0

A valid case is that it provides a telling signature, so those maintaining the app Can easily see which fields are passed in the Call.

The Builder pattern is, however a better solution for maintainability.

于 2010-02-16T08:08:19.667 回答
0

好吧，我看不出这段代码有什么问题。IDE 可以帮助您减少必须编写的代码量，这很好。

于 2010-02-16T07:35:02.440 回答
0

阴影总是不好的。在变量的作用域（而不是类型）之后命名变量，这样您就省去了麻烦。

于 2014-03-18T22:42:06.097 回答