this.field

[Jeanne Boyarsky]

Do you use "this.field" or "field" to refer to an instance variable?

I've been using "field" because it's less typing and tools pick up on it if you create another variable with the same name. But I saw that requiring use of "this.field" is an option in Eclipse 3.0. That got me thinking it might be more standard than I suspect.

[Brian Smith]

I normally don't use this unless there are methods arguments with the same name as instance variable. In that case, the method arguments may shadow the instance variable so I use this keyword to identify it from the method arguments. I am not sure if using this keyword is a standard.

Tulsi

[Adeel Ansari]

Jeanne,
I used to use 'this' keyword usually, but then once, a year back, my senior
said to me that avoid using 'this' in order to get some performance gain. Dont know if there is any, he didn't tell me how would it result in a performance gain. And I just started avoiding 'this'.

Now I dont use 'this'. But recently while doing jasper report, I got an error. I was using a collection of my VOs in order to fill the report. One of my Mutator method is like this.

public void setFirstName(String name){
   firstName = name;
}

It resulted in error. Dont remember the exact error message but it was something like FirstName is not found or illegal property. Not sure though.
then I just changed the method as below,

public void setFirstName(String firstName){
   this.firstName = firstName;
}

The code worked fine. And I dont know why Jasper has some concern with setXxx() method. It should rather go for getXxx() method. Anyways.

[Pradeep bhatt]

Using this.<field> is not a standard. It is usually used for variable name hiding purpose.

[steve souza]

My opinion is that using 'this' when not required is bad form. It makes the code less readable. I suspect 'this.var' and 'var' are compiled to the same byte code, so they should have the same performance. The only time I use this is to resolve an ambigous variable such as the local and instance variable having the same name.

[Jeanne Boyarsky]

Originally posted by steve souza:
The only time I use this is to resolve an ambigous variable such as the local and instance variable having the same name.

This is never an issue as I avoid having local and instance variables with the same name.

[Ilja Preuss]

The only people I know who use this (pun not intended) style of coding are those coming from the Smalltalk language, where it is the only way to refer to instance variables, and who are therefore simply used to it.

[Jeanne Boyarsky]

Ok. So I'll leave that option off in Eclipse. It sounds like everyone here avoids "this", so I can continue to do so without feeling non-standards.

[Jeroen Wenting]

Originally posted by Jeanne Boyarsky:

This is never an issue as I avoid having local and instance variables with the same name.

It can be handy in methods that set instance variables as it prevents you having to come up with more than one name for the same thing.

[Mark Spritzler]

Using "this" tends to fall under the variable hiding, like in setters where the argument is the same name as the instance variable.

And also if you want to call an overloaded constructor.

Mark

[Jeff Langr]

An idiosyncracy. One place that I use this is in equality methods. Old habit.

public boolean equals(Object obj) {
   if (!(obj instanceof Course)) return false;
   Course that = (Course)obj;
   return
      this.department.equals(that.department) &&
      this.number.equals(that.number);
}

For some reason I find it reads better, particularly when you have multiple comparisons, but it is wasteful. No one's smacked me for it yet.

-Jeff-

[Jeanne Boyarsky]

Originally posted by Jeroen Wenting:


It can be handy in methods that set instance variables as it prevents you having to come up with more than one name for the same thing.

Well the IDE writes getters and setters. I just configure it to add a prefix to the method parameter.

I used to agree, but have come across code like the following one too many times. It managed to slip into production once!

public void setField(String field) {
  field = field;
}

[Adeel Ansari]

Originally posted by Mark Spritzler:
Using "this" tends to fall under the variable hiding, like in setters where the argument is the same name as the instance variable.

And also if you want to call an overloaded constructor.

Mark,
I am fine with the first one but couldn't get you in second one, "And also if you want to call an overloaded constructor".

I can think of overrided methods though. we use 'this' for a clear call.

thanks

[Jeroen Wenting]

"Well the IDE writes getters and setters. I just configure it to add a prefix to the method parameter."

That's the road towards Hungarian Notation, which is a road of no return.
Soon you'll be writing things like lpsfz_l_p_someName and think it completely clear and natural!

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

public void setField(String field) {
  field = field;
}

You can configure the Eclipse compiler to give a warning or even a compile error for such code.

[Ilja Preuss]

Originally posted by Jeroen Wenting:


It can be handy in methods that set instance variables as it prevents you having to come up with more than one name for the same thing.

Well, for some time I tried prefixing the method parameter of a setter with "new":

value = newValue;

I found the

this.value = value;

to be more idiomatic, though.

[Jeanne Boyarsky]

You can configure the Eclipse compiler to give a warning or even a compile error for such code.

In 3.0 you can. We are still using 2.1. JTest (static analysis tool) picks it up, but why invite difficulties?

What about this one? (JTest picks this up too.) I don' recall whether Eclipse 3.0 does or not.

public setField(String field) {
  if ( field == null ) {
    field = ""; // BAD
  }
  this.field = field;
}

[ January 12, 2005: Message edited by: Jeanne Boyarsky ]

[Ilja Preuss]

It's certainly not something I would write, but why is it BAD???

[Mark Spritzler]

Originally posted by Adeel Ansari:


Mark,
I am fine with the first one but couldn't get you in second one, "And also if you want to call an overloaded constructor".

I can think of overrided methods though. we use 'this' for a clear call.

thanks

In order to call an overloaded constructor you must use this().

For instance

 
public class Test {
  public Test() {
    int i = 1;
    this(i);
  }
 
  public Test(int j) {
    System.out.println(i);
  }
 
  public static void main(String[] args) {
    Test test = new Test();
  }
}
 

When you create a Test class with the no args constructor the other constructor is called and 1 is printed out.

Mark

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:
It's certainly not something I would write, but why is it BAD???

Oops. That wasn't quite what I meant to write. It should have been:

public setField(String field) {
  if ( field == null ) {
    field = ""; // BAD
  } else {
    this.field = field;
  }
}

[Adeel Ansari]

Mark,
Now I got you. I was thinking somewhere else . I should have thought this before.

thanks.
[ January 14, 2005: Message edited by: Adeel Ansari ]

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

public setField(String field) {
  if ( field == null ) {
    field = ""; // BAD
  } else {
    this.field = field;
  }
}

Ah, I see. No, I don't think Eclipse is able to find that.

[Robert Hayes]

Doesn't using this. give you that warm fuzzy feeling that you're dealing with an instance variable?

Or... how about for lazy people that enjoy code completion?

I'm not for or against it but I wonder why people haven't brought these things up.

Oh... one other one: does the obvious indication that you're dealing with an instance variable heighten your awareness of whether its being used in a thread-safe manner?
[ January 14, 2005: Message edited by: Robert Hayes ]

[Ilja Preuss]

Originally posted by Robert Hayes:
Doesn't using this. give you that warm fuzzy feeling that you're dealing with an instance variable?

If I didn't knew this anyway, I would be in trouble, wouldn't I?

BTW, you can configure Eclipse to color instance variables in a different way from locals, parameters and class variables.

Or... how about for lazy people that enjoy code completion?

You don't need to type "this." for code completion, do you???

Oh... one other one: does the obvious indication that you're dealing with an instance variable heighten your awareness of whether its being used in a thread-safe manner?

Mhh, no, not really. Your mileage may vary, of course.

[Adeel Ansari]

 
public class Test {
  public Test() {
    int i = 1;
    this(i);
  }
 
  public Test(int j) {
    System.out.println(i);
  }
 
  public static void main(String[] args) {
    Test test = new Test();
  }
}
 

---

</blockquote>

Just reminding, Constructor call must be the first statement in a constructor.

I know you just wrote it casually. But perhaps someone try this and get some error.

cheers.
[ January 15, 2005: Message edited by: Adeel Ansari ]

[Ilja Preuss]

Originally posted by Mark Spritzler:
In order to call an overloaded constructor you must use this().

Yeah, but this is rather off topic to this thread, which is about the use of "this.<fieldname>"...

[Adeel Ansari]

Originally posted by Ilja Preuss:
Yeah, but this is rather off topic to this thread, which is about the use of "this.<fieldname>"...

thanks Ilja. So, i was right in thinking somewhere else.
[ January 15, 2005: Message edited by: Adeel Ansari ]

[Anselm Paulinus]

The use or non-use of this might depend on the coding style adopted by the team. I was not used to this until my present project where my team lead used the this prefix on a reqular basis, in order to make my codes as close to his as possible, I adopted it at least for the project. I do not think it has any effect on compilation speed or any that I can think of.

[Michael Feathers]

I do it all the time in constructors. It saves making up silly names for parameters when all you are going to do is assign them to a field.

If you use some sort of naming wart like an 'f' or underscore prefix for fields then there isn't much need to use 'this' in this way.

[Vladas Razas]

I do not put initializers when not needed for class fields:

SomeObject theObject = null; // I do not initialize with nulls.

I don't see how it can clarify anything and everybody know that class fields are initialized with default values. Also I do not put public in interface methods:
[code]
interface MyInterface {
public void letsGo(); // I do not put public here.
}

I think this is alike to "this" usage.