My opinion: use this
for disambiguation purposes, e.g., when a parameter name collides with a class property, otherwise leave it out for less noise.
For the pure sake of readbility and understandabilitly you should always use the this.
whenever you call an instance member. It is considered best practice and StyleCop suggests it too:
(With the this prefix) all calls to class members (are) 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.
In other words, if you omit the this. prefix you can not quickly understand, wether soemthing is a static member, a local variable, a delegate ... With the prefix you'll see it at first glimpse.
But the most important thing is: Whatever you chose, you should keep it consistent across the whole file, and across all other files and propably also across your whole team !
Effectively the this
keyword used in the context you describe is most useful as a disambiguator if you have more that one item in scope with the same name (e.g. an instance variable and a local variable of the same name)
one way you really need it is when pass a parameter named as the member
in constructors
Myclass(int id) { this.id = id; }
When referring to a variable, this.
can distinguish between a local variable or a parameter, and a member variable. But when referring to a method, it doesn't offer any useful distinction, and is therefore, to my way of thinking, codejunk. Leave it off.
You've got two disagreeing answers so far so I'll add my perspective as an ex-Java, ex-C# and now a mostly-Python programmer. In Python we have self
that does pretty much the same job, just it's not optional.
I would say use this
as often as you can. It doesn't change anything as it's implicit when you call it from within an object but it does help differentiate so you know you're calling a class member (vs a global function).
You'll appreciate it when you read over the code in a year's time.
I normally don't leave 'this.' in code at all. But I do use it for intellisense purposes when I can't remember what 'this.' contains. Then I remove it.
But one instance you have to keep it, is to qualify members hidden by similar names. For example:
public Employee(string name, string alias)
{
this.name = name;
this.alias = alias;
}
You don't need it if the call is not ambiguous, but I prefer using it, too. In my opinion, it is simply consistent for Bar to access properties and methods of Foo by foo.Property and foo.Method(), and access its own members as this.Property and this.Method(). You're still dealing with properties and methods of objects, except in the case of this
, you're dealing with members in the same class. But why should that matter regarding coding style?
I use this
all the time. It's clean, it's clear, and it's consistent.
Several people have mentioned the use of this
with regard to member variables. I would recommend...
Either:
- Prefix member variables with
this.
Or:
- Adopt a naming convention for member variables that requires you to name them with a
_leadingUnderscore
Stylecop rules can be set to enforce whichever of these rules your team prefers.
This points to the current object, it's basically used to remove the ambiguity of
method/variable names for e.g.
public class Test
{
private string name;
public Test(string name)
{
this.name = name;//using this coz the parameter name and variable names are same
}
}
You don't need to use it always.
I hope it helps you.