I've seen some guides or blogs that say using this to access a class's own members is bad. However, I've also seen some places where professionals are accessing with this. I tend to prefer explicitly using this, since it seems to make it clear that the thing I'm accessing is part of the class.
this.MyProperty = this.GetSomeValue();
Is there some advantage or disadvantage to using this? Is it simply a stylistic preference?
It's frowned upon, almost all of the time in general use. I never use "this" like that.
People do it because they get Intellisense in their editor by typing "this" and then a "dot". You also see it around a lot of places when automatic code generators are doing the coding.
Now as to the question to why using "this" throughout your code is a bad idea. First off, it can be used as a crutch to cover up the lack of a good naming convention. For example, I consider this block of code to be a "coding horror":
class Fudge {
public decimal PoundsOfChocolate {get; set;}
Fudge (decimal PoundsOfChocoloate) {
this.PoundsOfChocolate = PoundsOfChocolate;
}
}
Yuck. Better to use an agreed upon naming convention:
class Fudge {
public decimal PoundsOfChocolate {get; set;}
Fudge (decimal poundsOfChocoloate) {
PoundsOfChocolate = poundsOfChocolate;
}
}
Why is this better? Well, in the trivial case like the above example, it doesn't matter all that much. Things get worse when your functions get longer, and you have private variables in complex functions which might collide with your members.
Also, if you pepper your code with "this" keywords, it becomes more difficult to read since there is more repetitive text. And it is just more verbose without adding semantics. IMO more verbosity without added semantics is bad. My two cents. Downvote all you want.
That isn't to say that "this" has no valid uses. Far from it. If you use it to resolve the difference between calling a base member and a member in the current object, then it has its place. It has its place in code generators as well. But as whiskey has taught me, overuse of anything leads to pain.
It's sometimes necessary, e.g. in a constructor (in C# or Java) if you are assigning a field from a parameter of the same name.
If it adds to the clarity of the code, use it , if it doesn't don't. There are a few places it does add clarity - for example in C++:
struct Point {
int x, y;
Point & operator=( const Point & p ) {
this->x = p.x;
this->y = p.y;
return *this;
}
};
In cases like this, when you have two objects of the same type to refer to I find that the use of this can clarify things (though note that in C++ the above assignment operator implementation is not necessary).
I agree with Dave. It is longer.
It is simply a matter of style, there is no other effect.
It's primarily used for constructors and initialization functions (and I prefer this style to various underscores):
MyClass(hisValue) { this->hisValue = hisValue; }
Using this style everywhere is just a syntax bloat reminiscent of Hungarian notation. If you keep functions reasonably short, local variables and function parameters are immediately recognizable to the reader of code. If declaration is not within screen, it can can be assumed then to be a class member - so 'this' notation doesn't add any useful information.
Regarding to C++, when using templates it's sometimes necessary to use this to help compiler with name resolution:
template <typename T>
class Base {
public:
void exit();
};
template <typename T>
class Derived : Base<T> {
public:
void foo() {
exit(); // calls external exit() or error
// so you should use this->exit() if that was your intent
}
};
I always use this. because it makes code more readable in my opinion. It makes instantly clear that
base.) or the overriding member (this.)this.Monster.Legs.Run(); vs Monster.Legs.Run();).In objective-c
...
prop = value; // just an assignment
...
and
...
self.prop = value; // !!! equivalent to method call [self setProp:value]
...
differ much - you must be aware of what and why you're doing.
I always use this for a simple reason:
(Example in C# but won't make a difference)
Take for example a class like this:
class Foo {
private int count = 0;
public List<Int32> foos = new List<Int32>();
public int DoCounting() {
foreach (Int32 foo in foos) {
if (foo > 50) ++count;
}
return count;
}
}
Now another coder of your company has to add a function quickly, i.e. count another loop. He doesn't look at your code but simply adds his own due to the time critical request (or because it's 11:59am and he wants to make a break):
class Foo {
private int count = 0;
public List<Int32> foos = new List<Int32>();
public List<Int32> bars = new List<Int32>();
public int DoCounting() {
int count = bars.Count;
for (int i = 0; i < count; ++i) {
bars[i]++;
}
foreach (Int32 foo in foos) {
if (foo > 50) ++count;
}
return count;
}
}
Now what happens? And how easily could this be prevented by always using this?
Ofc the example is unrealistic but it happens easily in more complex classes and methods and causes hard to track bugs.
The general rule should be: use "this" to avoid ambiguity, don't use this if it's obvious to what you refer.
For example, when progamming in Java, this.getSomeValue() is not needed, since all function calls are method calls on "this". On the other hand, this.myProperty might be useful if there are lots of local variables within your method, or if there are static member variables, and you want to make clear that you access an instance variable.
Of course, sometimes "this" is unavoidable, as in
void setX(int x){ this.x = x; }
Having gone from using this for years, to finding not many people (atleast in my experience) use it, I eventually changed. The benefits I can see of having this-less code:
_myVar for private variables, which don't need a this as they're always member variables.e.g.
someclass.Method(1);
SomeClass.StaticMethod(1);
I can see that if you don't use the underscores naming convention, and have a large method with a weighty body it could lead to some confusion.
Static methods or properties can occasionally confuse things, but very rarely.
You will obviously always need the this keyword when passing references, for example:
someclass.Method(this);
var someclass = new SomeClass(this);
(I write C#, but my answer relates to Java)
I use this, because it seems more readable to me. And...
StyleCop rule SA1101: PrefixLocalCallsWithThis says:
Cause
A call to an instance member of the local class or a base class is not prefixed with ‘this.’, within a C# code file.
Rule Description
A violation of this rule occurs whenever the code contains a call to an instance member of the local class or a base class which is not prefixed with ‘this.’. An exception to this rule occurs when there is a local override of a base class member, and the code intends to call the base class member directly, bypassing the local override. In this case the call can be prefixed with ‘base.’ rather than ‘this.’.
By default, StyleCop disallows the use of underscores or m_ to mark local class fields, in favor of the ‘this.’ prefix. The advantage of using ‘this.’ is that it applies equally to all element types including methods, properties, etc., and not just fields, making all calls to class members instantly recognizable, regardless of which editor is being used to view the code. Another advantage is that it creates a quick, recognizable differentiation between instance members and static members, which are not be prefixed.
A final advantage of using the ‘this.’ prefix is that typing this. will cause Visual Studio to show the IntelliSense popup, making it quick and easy for the developer to choose the class member to call.
How to Fix Violations
To fix a violation of this rule, insert the ‘this.’ prefix before the call to the class member.
Using this makes codes more cleaner and readable. Also you have no option but to use in a situation where the parameter name is the same as a member variable. How do you distinguish the two?
class Test {
int a;
void doA(int a) {
this.a = a; //if you do a=a its gonna be a bug really hard to catch
}
}
I would suggest always using this unless the code would behave differently if you did not. It at least acts as syntactic sugar for the programmer/reader to indicate that the RHS is coming from the current class.
Also, in some languages (Perl being one), if you leave off the object reference, then the inheritance heirarchy is not used when resolving the RHS. e.g. if methodName is defined in the parent, then $this->methodName() will work, but methodName() will fail because only the current package is searched.
It is really useful in a constructor where code like
this.field = field;
becomes more readable. I would put in methods too! Coloring of this doesn't hurt either.