tags:

views:

235

answers:

10
+10  A: 

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.

RedFilter
When you code changes (wich it usually does) you will always have to update all the places that have now become ambiguos or are not ambigous anymore. Reality shows us that you will most likely not do it, leaving your code in an inconsitent state - readability wise.
bitbonk
+5  A: 

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 !

bitbonk
I completely disagree and think that used superfluously, the this keyword adds only noise.
spender
This depends on what's more readable, maybe `this.` is more readable *for you*, however *I* find it's clutter and slows my parsing of the code down. Your answer makes this seem absolute, it is not, and may very per programmer or per team.
Nick Craver
(Per my own answer) I agree with this one. Consistent verbosity is much better than occasional curtness when it comes to code-readability.
Oli
@Nick Craver that's why I wrote, "you should" and not "you really have to". ;)
bitbonk
@Oli: I think you are overstating your case; I would use *occasional* in reference to using `this`, not to excluding it.
RedFilter
@bitbonk - Actually what you wrote is "you should **always** "...that I disagree with. When I have a generated LINQ-to-SQL template for example, is it necessary for me to see an extraneous (to me) `this` several hundred or thousand times?...I don't think so, maybe you disagree and that's fine...which is the point of my comment, this isn't an absolute. Also, StyleCop isn't 100% right on best practices, ever notice that formatting in VS for the past decade doesn't even comply with StyleCop? :)
Nick Craver
A: 

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)

spender
A: 

one way you really need it is when pass a parameter named as the member

in constructors

Myclass(int id) { this.id = id; }

Arseny
+1  A: 

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.

Carl Manaster
It distinguishes instance methods from static methods (and delegates), which is extremely useful when your codebase contains both.
Jeff Sternal
Thanks for the correction, @Jeff; I wasn't aware one could have static and instance methods of the same name in C#; I would consider it a bad practice - but I'm a Java guy. I'll update the answer.
Carl Manaster
@Carl - sorry, I wasn't clear! I didn't that mean you can have static and instance methods with the same name in C# (you can't), just that it's valuable to know *at the call site* whether what you're calling is a static or instance member (or delegate).
Jeff Sternal
@Jeff, thanks - that's a relief. Rolled back my answer. I don't agree that there's much value in knowing whether you're calling a static or instance method, and since within the IDE you can find out by pointing at it, I'll stand by my codejunk designation.
Carl Manaster
+2  A: 

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.

Oli
A: 

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;
} 
Ed B
+1  A: 

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.

Anthony Pegram
A: 

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.

Richard Ev
A: 

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.

Praveen