• Post Reply Bookmark Topic Watch Topic
  • New Topic

same variable name for instance and local variable  RSS feed

 
ben oliver
Ranch Hand
Posts: 375
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In code if it looks like

public class Test {

private String name;

public void inti() {

name = "abc";
...
}

public void do() {

String name;
name = grabAnotherName();

// work on "name" variable
..
}

public String grabANotherName() {

...
// return some String for 'name";
}

***************

I use same syntax "name" for both an instance variable and a local variable.

my question is --- when the code executes in "do()" method and work on "name" variable, does it actually use the local variable ? I tested it and it seems it is using the local variable, but does it cause any problem by using the same name ?
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is called 'Shadowing'.

If you define an instance and a local variable and later on refer to it without using this then you use the local variable.
Using this.name refers to the instance variable, even if a shadowed variable is present.
 
Jarred Olson
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also using code tags can make it a lot easier to read Code Tags

For example:

 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only problem is one of clarity: unless you have a very good reason to do this, and I can't think of any, don't.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:The only problem is one of clarity: unless you have a very good reason to do this, and I can't think of any, don't.
The only place I would say shadowing is respectable is in constructors and set methods, like thisNote the use of the this keyword to distinguish the field from the local variable or parameter.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep; I should have said that.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Yep; I should have said that.
Maybe not; the point I raised about constructors is something people disagree about.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Meh... I actually still tend to use leading underscores for members, trailing for parameters--solves the problem, and even though it makes the code a bit uglier, it makes things stand out when I'm looking at code outside of an IDE, which is quite often for me.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66306
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Meh... I actually still tend to use leading underscores for members, trailing for parameters--solves the problem, and even though it makes the code a bit uglier, it makes things stand out when I'm looking at code outside of an IDE, which is quite often for me.

Ugh! To each.

For me, I prefix all instance references with this., regardless of whether it's needed for disambiguation or not. There are those who barf at that, but I like the fact the references are consistent no matter where they are (rather than it meaning one thing in one location, but something different elsewhere). To each...
 
salvin francis
Bartender
Posts: 1653
37
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:Meh... I actually still tend to use leading underscores for members, trailing for parameters--solves the problem, and even though it makes the code a bit uglier, it makes things stand out when I'm looking at code outside of an IDE, which is quite often for me.


We should always realise the fact that the code written by us is probably going to be read by others. In such such cases, using self conventions
causes inconvenience to all those refering to it hence forth.
I am not arguing that a given approach is right/wrong, there are plenty of standards already into existence that many follow.

Personally i prefer shadowing in constructor/methods.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
salvin francis wrote: . . . In such such cases, using self conventions causes inconvenience to all those refering to it hence forth. . .
At least Bear's convention of using the this keyword throughout is unambiguous and impossible to misunderstand.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
salvin francis wrote:We should always realise the fact that the code written by us is probably going to be read by others. In such such cases, using self conventions causes inconvenience to all those refering to it hence forth.

I actually started doing that after working at Morgan Stanley, where their 5000 developers follow that standard.

If somebody can't figure it out within a few minutes of looking at the code there's no possible way I would hire them anyway.

While I agree that in getters/setters using this is very clear, IMO it's too bulky to refer to properties that way throughout non-getter/setter code, and in non-IDE situations I've really enjoyed having it obvious what's a property, what's a parameter, and what's local: not everybody writes tiny little methods like I do.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Newton wrote:I actually started doing that after working at Morgan Stanley, where their 5000 developers follow that standard.


Having known quite a few people who went to MS, and having worked with MS on a few projects, it would be fair, IMO, to say they have some of the smartest people that I know. They also seem to have some very "particular" standards, that don't seem to follow the outside world. Now admittedly, over the last few years, they have gotten much better.

David Newton wrote:
If somebody can't figure it out within a few minutes of looking at the code there's no possible way I would hire them anyway.

While I agree that in getters/setters using this is very clear, IMO it's too bulky to refer to properties that way throughout non-getter/setter code, and in non-IDE situations I've really enjoyed having it obvious what's a property, what's a parameter, and what's local: not everybody writes tiny little methods like I do.


David, you do know that the statement can be reversed right? Yes, you have the right to not hire someone that can't figure that standard out -- or unwilling to conform. But what if the company standard is the standard that Bear uses? Which interestingly, is more common than the standard you are using (okay, maybe not the "every instance variable" part, but the using "this" part).

Henry
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you do know that the statement can be reversed right?

Of course. OTOH, I wouldn't want to work for someone that wouldn't hire me because at some jobs I use underscores, so it's all good.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!