• Post Reply Bookmark Topic Watch Topic
  • New Topic

name conflict  RSS feed

 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

why same name of variable can be used as a local variable ? no name conflict ?

Thanks.

 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Edward Chen wrote:
why same name of variable can be used as a local variable ? no name conflict ?

Thanks.



Local scope has higher preference than the class scope. So it considers the value of the local scope. Its called- Shadowing of variables. Had written an article related to this few years back.
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's all in the JLS.
http://java.sun.com/docs/books/jls/third_edition/html/names.html
 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not recommended to shadow variables because it doesn't add any functionality but only confuses.
 
Alex Hurtt
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Edward Chen wrote:
why same name of variable can be used as a local variable ? no name conflict ?

Thanks.



Situations like this are called shadowing as somebody previously mentioned. They are generally undesirable because they can lead to bugs. But if you must do this for whatever reason, that is why the 'this' keyword exists, so that you can clearly differentiate when you are referring to the 'name' variable in local scope vs. that 'name' variable at instance member scope. If you want to reference the instance level scoped 'name' variable from within the body of your test() method in this case, you must do so by referring to it as 'this.name' so long as you have the identically named 'name' variable also declared local to your method scope. If you rename you locally scoped 'name' variable to something else, you no longer need to refer to the instance scoped 'name' variable as 'this.name' because in that case the 'this' is implicitly inferred since there would be no local 'name' variable to take precedence over it. However, it is still considered best practice to refer to instance scoped member variables explicitly prefixing them with 'this.' so that it will always be very clear exactly what 'name' variable you mean whether or not there exists a locally scoped variable of the same name and you will never have bugs due to shadowing. But like I said, it's best still to just avoid shadowing whenever possible.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex Hurtt wrote:. . . it is still considered best practice to refer to instance scoped member variables explicitly prefixing them with 'this.' . . .
Are you sure that is a general rule? I quite like this.foo myself, but how many other people do?
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Are you sure that is a general rule? I quite like this.foo myself, but how many other people do?


Agree with Campbell. The other day I had written some code for my practical exams and had used ...


... in the contructor. The person who was evaluating didnt like the usage and was a bit confused.

I have seen in Production code as well that this.<variable_name> is not used extensively or is rarely used
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
mohammed sanaullah wrote: . . . had used ...


... in the contructor. . . .
That is the one instance where this.variable is particularly good. I am surprised your instructor was unfamiliar with that usage.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
mohammed sanaullah wrote: . . . had used ...


... in the contructor. . . .
That is the one instance where this.variable is particularly good. I am surprised your instructor was unfamiliar with that usage.


Yeah the instructor was not familiar with that one Usually the auto-generated getters and setters use- "this".
 
Alex Hurtt
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Alex Hurtt wrote:. . . it is still considered best practice to refer to instance scoped member variables explicitly prefixing them with 'this.' . . .
Are you sure that is a general rule? I quite like this.foo myself, but how many other people do?


Not so much a hard and fast rule but a general guideline that if you get into the habit of following religiously will lead to much more readable/clear/maintainable code especially when you are working in an environment where multiple people might be maintaining the same code base. You want to be sure that the new guy who comes along and adds a local variable to some method with the same name as an already existing instance variable and which that existing method he's modifying already references, he's not breaking your existing code. It's not really a question in my mind about like/don't like. It's just safer and more concise to use 'this.' whenever referring to instance member variables.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex Hurtt wrote:
You want to be sure that the new guy who comes along and adds a local variable to some method with the same name as an already existing instance variable and which that existing method he's modifying already references, he's not breaking your existing code.


Is it a good approach to add a new variable with the same name as an existing instance variable? May be other more experienced Ranchers would be able to comment. But during the code reviews such instances are often pointed.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with you both; I like this.x and agree it is probably not a good idea to introduce shadowing variables. What I was querying is whether this.x is a widespread rule.
 
Stephan van Hulst
Saloon Keeper
Posts: 7973
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally I only and always use the same variable name in the constructor, and in simple setters.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with Stephan van Hulst.
 
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
Campbell Ritchie wrote:
Alex Hurtt wrote:. . . it is still considered best practice to refer to instance scoped member variables explicitly prefixing them with 'this.' . . .
Are you sure that is a general rule? I quite like this.foo myself, but how many other people do?

Me. Always,
 
Alex Hurtt
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
mohamed sanaullah wrote:
Alex Hurtt wrote:
You want to be sure that the new guy who comes along and adds a local variable to some method with the same name as an already existing instance variable and which that existing method he's modifying already references, he's not breaking your existing code.


Is it a good approach to add a new variable with the same name as an existing instance variable? May be other more experienced Ranchers would be able to comment. But during the code reviews such instances are often pointed.


No it's not a good approach in my opinion. But that won't stop the new guy from doing it anyway (and not necessarily on purpose either). In an environment where a lot of people work on the same code base and there is personnel turnover, new people coming on board and leaving from time to time, there are going to be some people who come on who are more experienced and some who are less experienced and have different habits than others. So in cases like this it's best to use defensive programming techniques such as always use 'this.' whenever referring to a class level instance variable. Because it's like driving...you can be the best most cautious driver in the world but if you aren't thinking about what the other guy might do, you can still be involved in a wreck.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex Hurtt wrote:In an environment where a lot of people work on the same code base and there is personnel turnover, new people coming on board and leaving from time to time,


Code reviews help in such cases. Coming back to large code base- I believe They have their own code conventions.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!