1

Possible Duplicates:
Why does StyleCop recommend prefixing method or property calls with “this”?
When do you use the “this” keyword?

Hi SO, and happy Friday I have a question regarding the use of this.method();. My code seems to work without using the this., but I include it because it seems like the right thing to do. When should .this be used, and because it's presence doesn't always make a difference, what's the best practice for .this?

Community
  • 1
  • 1
sooprise
  • 22,657
  • 67
  • 188
  • 276

10 Answers10

10

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.

D'Arcy Rittich
  • 167,292
  • 40
  • 290
  • 283
  • 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 May 28 '10 at 13:58
5

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
  • 48,890
  • 37
  • 186
  • 278
  • 5
    I completely disagree and think that used superfluously, the this keyword adds only noise. – spender May 28 '10 at 13:28
  • 3
    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 May 28 '10 at 13:28
  • 2
    (Per my own answer) I agree with this one. Consistent verbosity is much better than occasional curtness when it comes to code-readability. – Oli May 28 '10 at 13:33
  • @Nick Craver that's why I wrote, "you should" and not "you really have to". ;) – bitbonk May 28 '10 at 13:45
  • @Oli: I think you are overstating your case; I would use *occasional* in reference to using `this`, not to excluding it. – D'Arcy Rittich May 28 '10 at 13:51
  • @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 May 28 '10 at 13:57
2

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
  • 235,628
  • 64
  • 220
  • 299
1

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
  • 39,912
  • 17
  • 102
  • 155
  • It distinguishes instance methods from static methods (and delegates), which is extremely useful when your codebase contains both. – Jeff Sternal May 28 '10 at 13:49
  • 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 May 28 '10 at 14:34
  • 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 May 28 '10 at 14:37
  • @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 May 28 '10 at 14:56
  • @JeffSternal: since instance methods invocations from within the same class are likely to be much more common than static method invocations, I would only qualify the static method invocations, so as to use shorter constructs for more common things and longer constructs for less common things. – ninjalj Sep 01 '12 at 09:52
1

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
  • 123,721
  • 27
  • 225
  • 246
0

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
  • 117,338
  • 33
  • 229
  • 351
0

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

in constructors

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

Arseny
  • 7,251
  • 4
  • 37
  • 52
0

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
  • 6,028
  • 3
  • 26
  • 35
0

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
  • 52,939
  • 59
  • 191
  • 278
0

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.

Embedd_0913
  • 16,125
  • 37
  • 97
  • 135