是“这个”吗？影子是个好主意吗？
隐藏类变量的情况在 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”并引入错误的风险。
普遍的共识是什么？禁止阴影，有时允许，还是让它滚动？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我实际上更喜欢“仅在构造函数和设置器中允许阴影”的准则。其他一切都是不允许的。
省去了命名构造函数参数
aValue和aTest的麻烦，只是为了避免阴影。如果您使用的是 eclipse，它的警告设置可以精确设置为该选项顺便说一句。
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
aValueandaTestjust to avoid shadowing.If you're using eclipse, its warnings settings can be set exactly to that option BTW.
在使用 Eclipse 和 IntelliJ IDEA 等 IDE 时，我对变量阴影感到安全，它们会以与局部变量不同的颜色突出显示字段，并且还提供有关局部变量误用的有用警告。
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.
遮蔽在简单的代码中非常有用，例如构造函数、getter、setter 以及任何类似的代码。
然而，描述性变量的使用确实很重要，所以不要使用这个
this.name = name;尝试这个this.name = newName;另外，如果你养成这样的习惯在代码中包含
this.它会成为第二天性，并且对可读性有很大帮助Shadowing can be useful in simple code such as constructors getters setters and anything of the sort.
However the use of descriptive variables is really important so instead of using this
this.name = name;try thisthis.name = newName;Also, if you make a habit of including
this.in your code it becomes second nature and helps quite a bit with readability像 Eclipse 这样的优秀 IDE 会以不同的颜色和/或字体向您显示类的属性和方法变量。因为变量阴影是可以的。
A good IDE like Eclipse shows you, in different colours and/or fonts, the attributes and the method variables of your class. Becaus of that variable shadowing is OK.
实际上，我将 Eclipse 安装设置为对每个不合格的变量发出警告。这确保我永远不会忘记在实现变量前加上
this.前缀。这有效地解决了阴影可能出现的任何问题。您可以通过“首选项”>“选项”来执行此操作爪哇>编译器>错误/警告>>代码风格>对实例字段的不合格访问。
I actually set up my install of Eclipse to issue warnings for every under-qualified variable. This ensures I never forget to prefix implementation variables with
this.. This has effectively preemptively solved any problem that might arise from shadowing.You can do this by way of Preferences > Java > Compiler > Errors/Warnings >> Code Style > Unqualified access to instance field.
我一直在做“这个”影子。在复杂的地方，使用显式的
this很有用，即使它不隐藏任何东西。从人类的角度来看，它使得区分局部变量和类变量变得更容易（尽管如此，你必须保持一致；到处使用this，但不是到处都令人困惑）。在 Python 中，您甚至没有选择：普通的
x始终是本地的。类成员是self.x。I do "this" shadowing all the time. In complex places, it's useful to use an explicit
thiseven if it doesn't shadow anything. It makes it easier to distinguish between local and class variables, from the human viewpoint (although, then it becomes an issue that you must be consistent; usingthisa little bit here and there but not everywhere is confusing).In Python, you don't even have the choice: plain
xis always local. Class members areself.x.嗯，我没有发现这段代码有任何问题。 IDE 可以帮助您减少必须编写的代码量，这很好。
Well, I dont see any problem with this code. Its good that IDE is helping you to reduce the amount of code that you have to write.
一个有效的例子是它提供了一个有说服力的签名，因此维护应用程序的人可以轻松查看调用中传递了哪些字段。
然而，构建器模式是可维护性更好的解决方案。
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.
样式规则的主要理由是使代码对于原作者和需要维护代码的其他人来说都是可读的。在这种情况下，可读性是指能够在机械层面和更深层次的语义层面轻松理解代码的实际用途。
一般来说，（除了构造函数和设置器之外）变量隐藏往往被认为是不好的风格，因为它会导致临时读者将局部变量的使用误认为是成员的使用，反之亦然。 （突出显示成员名称的 IDE 往往会减轻这种情况，但仍然很容易错过这种区别。）并且（除了构造函数和 setter 之外）本地成员和同名成员之间通常存在明显的语义区别，并且使用不同的名称可以最好地反映这一点。
Setter 和构造函数在上述各个方面都略有不同。由于设置器（特别是）和构造器简单且程式化，因此隐藏所显示的形式不太可能导致随意的读者和混乱。事实上，我认为仅使用一个标识符来表示本质上相同的信息实际上可能会使代码更易于阅读。
在此基础上，我想说隐藏在构造函数和设置器中是完全可以接受的。严格要求你应该避免在这种情况下隐藏的风格规则（在我看来）是迂腐的，而且可能会适得其反。这肯定与大多数 Java 程序员所认为的正常做法不一致。
The main justification for style rules is to make code readable, both to the original author and to others who need to maintain it. In this context, readability is about being able to easily understand what the code actually does, both at the mechanistic level and at the deeper semantic level.
In general, (apart from constructors and setters) variable hiding tends to be considered bad style because it causes the casual reader to mistake uses of locals for uses of members, and vice versa. (An IDE that highlights member names tends to mitigate this, but it is still easy to miss the distinction.) And (apart from constructors and setters) there is generally a clear semantic distinction between the local and the member with the same name, and this is best reflected by using different names.
Setters and constructors are a bit different in each of the respects above. Since setters (in particular) and constructors are simple and stylized, the hiding of the form shown is unlikely to cause a casual reader and confusion. Indeed, I would argue using only one identifier for what is essentially the same information may actually make the code easier to read.
On this basis, I would say that hiding in constructors and setters is perfectly acceptable. A style rule that rigidly insists that you should avoid hiding in this context is (IMO) pedantic and maybe counter-productive. And it is certainly out of step with what most Java coders would consider to be normal practice.
阴影总是不好的。根据变量的范围（而不是类型）来命名变量，这样就可以省去麻烦。
Shadowing is always bad. Name your variables after their scope (not type), and you'll save yourself the hassle.