Possible Duplicate:
Do you prefix your instance variable with 'this' in java ?
Coding standards question. Maybe should be Wiki, let me know. Should I qualify all my instance properties and methods with this. or should I leave it off. Do you think it makes statements more readable and traceable? Or is it just a few wasted keystrokes?
I'm not sure there is a definitive answer one way or the other. In my opinion it does help readability, but I can see where people might think it clutters up the page.
I mainly use "this" to help point out the difference between instance and static members. But if I don't have a mix I would normally avoid the "this"
Leave it off, it doesn't bring any value. Even ReSharper suggests you should remove it because it is redundant.
The advantage is that it can prevent silly mistakes like this:
private String value;
public void setValue(String value) {
value = value;
}
But I would still be inclined to not require it. Especially if you are using an IDE that color codes the difference.
A nice convention if you want to prevent the mistake with a standard of always using this is Hungarian notation where fields are prefaced with an f, so the example becomes:
private String fValue;
public void setValue(String value) {
fValue = value;
}
You see that convention in the JUnit source code, for example.
Using a good naming convention obviates the need for using "this" for readability.
I use this when I think it will communicate more clearly without cramping my style. In particular, set methods are a great place where I like to have the clear match between the data member and the method parameter:
public void setImportantValue(double importantValue) {
this.importantValue = importantValue;
}
With colorized IDEs, this is a little bit redundant but if it helps me work better with my fellow humans, it's a win.
Edit: Thorbjørn reminded me of an excellent point:
Using "this" allow you to have the same name for the parameter as for the field, which clearly shows intent. Also the parameter name ends up in the signature which is what you see in the IDE - having correspondence between setter name and argument removes all doubt.
I was reminded that the user of your code usually only sees your external API. For example, if we want to make it clear to the user (either via javadoc, code completion or IDE mouse-overs) that a method is going to adjust the Euler angles of a simulated airplane, we might use a method such as:
public void setOrientation(double roll, double pitch, double yaw) {
this.roll = roll;
this.pitch = pitch;
this.yaw = yaw;
}
It is clear from the externally-exposed interface and the parameter names what I'm trying to accomplish. I could even make things a little more clear with @param javadoc tags.
The fact that I need to do a little more typing of "this.roll", etc., is a very small price for me to pay to make the both API-user's life easier and the API-maintainer's task more clear. This is especially true since I only pay the price once.
I always use it - I find it helps me think more about what I'm doing, and if something should be scoped to the class.
I didn't use it before I started running StyleCop on everything - now I've converted.
It does bring a provide distinction between local and instance variables, for one. this can easily replace prefixes some people like to use for that purpose. For me, though, I like to use for IDE autocompletion- it's a bit lazy, but oh well.
I say "only if necessary" as in
public void setFoo(Foo foo) {
this.foo = foo;
}
The big disadvantage to using it other places is that if you want to change between instance/static/local you have more work to do. (I just had to do this to some code and it wasn't fun...)
I limit the use of the keyword this in my code to only those situations that it is necessary to achieve the correct behavior.I would avoid using it whenever it is already understood.
Examples of where 'this' is required to achieve desired behavior include constructors and often in equals(Object o) method implementations.
IMHO the clarity is always worth a few extra characters, and is a far stronger defence than relying on an ephemeral naming convention.
Saving on typing has always been a weak excuse.
Using this for clarity in general is not really useful, since if you have to make it explicit to distinguish it from others, you probably should clear up your method a lot, maybe dividing it into sub methods. An exception is the setter method pattern, so that you don't have to invent arbitrary prefix for the instance variable.
When code contains additional elements that doesn't bring anything useful, the meaning of program gets cluttered. If you prefer using this, why not also qualify every object instead of importing it?
matter of taste I think. a proper naming convention generally makes use of "this" unnecessary.
I really don't understand why people put this in front of method invocations.
this.someMethod();
someMethod() could be in this class, the parent's class, or static. In this case this doesn't add any value or information. So I'd say in the case of methods, don't use this.
I always prefix instance variables with 'this'.
It makes the code more robust in the face of refactoring. For example, if an instance variable is being used in a method and I add a local variable or method parameter with the same name without realising my mistake, then I have introduced a bug without any warning from the compiler.
It makes it more obvious which variables are instance variables. Generally speaking, the more instance variables you have the more vulnerable your code is to multi-threading issues. I'm not saying you should avoid instance variables, because there are cases when they make your code cleaner, but its nice to be able to see at a glance where they are. The 'this' qualifier is the best way of achieving this.
It allows the IDE to provide code completion, thereby resulting in LESS typing, not more.
Code is not always viewed in an editor that has syntax highlighting. e.g. some diff tools.