views:

393

answers:

8

If I am accessing a member field, property, or method, I'm never sure when I should prepend it with 'this'.

I am not asking about cases where it is required, like in the case where a local variable has the same name. I am talking about cases where the meaning is exactly the same. Which is more readable? Are there any standards, best practices, or rules of thumb I should be following? Should it just be consistent throughout a class, or an entire code base?

A: 

In my code, I only use this.<PropertyName> when the property is a member of a base class, not the class I'm currently in.

Of course, not using 'this' at all is another popular choice, since it's unnecessary code being added.

Tejs
Why not use base.Name instead?
Ian P
I could do that as well. It's more of just a reminder that the property is not local to this particular code file.
Tejs
+10  A: 

I disagree with StyleCop on this one, and I'm not even sure that StyleCop's opinion should be interpreted as an official Microsoft guideline anyway. It was an internal tool used at Microsoft but not all teams use it, and not all teams use all the rules.

Adding this everywhere is not necessary and often just adds clutter. It does not improve performance and I'm not convinced that adding this all over the code improves readability either.

You might hear arguments that it makes it more clear where the variable is defined, but I would argue that if your class/method is so long and complicated that it is difficult to work out where something is declared then you probably should refactor it anyway. If you use the single responsibility rule and have short functions it should be obvious whether a variable is a member, a function parameter or a local variable.

As you point out, sometimes it is necessary. For example in the constructor if you want to set a private member with the same name as the parameter.

public class Foo
{
    private Bar bar;

    public Foo(Bar bar)
    {
        this.bar = bar;
    }
}
Mark Byers
If you use FxCop for static code analysis, your functions will never be too long, as it checks for cyclomatic complexity.
Kevin Albrecht
@Kevin Albrecht: Cyclomatic complexity is nothing to do with function length. It's to do with the number of different paths through the code. It's possible to have short functions with high cyclomatic complexity and long functions with low complexity.
Mark Byers
I understand that, but they are obviously related.
Kevin Albrecht
@Kevin Albrecht: Sure there is often a correlation. I just don't agree that checking cyclomatic complexity guarantees "functions will never be too long". I've certainly seen examples where this is not true.
Mark Byers
+1 for having sanity.
Chris Lively
Actually, you don't need to use this.bar in your example - the compiler is smart enough to "guess" that you want to set the private member to the specified argument, and not the other way around. This is also indicated in the intellisense popup if you start typing "bar".
Olli
+11  A: 

I recommend using Microsoft's guidelines, as verified by StyleCop: http://blogs.msdn.com/sourceanalysis/

The general rule is, prepend members with "this." when they are defined in the class, unless they are static, in which case you cannot.

Here is the rule directly from StyleCop:

SA1101: The call to {method or property name} must begin with the
'this.' prefix to indicate that the item is a member of the class.
Kevin Albrecht
I got in the habit of doing this in my C# codes years ago primarily to take advantage of intellisense, and it's stuck. Funny I don't do this for C++ (primarily code there using vim this-> is just an extra 6 characters to type then ;).
Nathan Ernst
+1  A: 

If you follow Microsoft's StyleCop, you should always use prefix class members with the this keyword.

SA1101: PrefixLocalCallsWithThis
TypeName: PrefixLocalCallsWithThis
CheckId: SA1101 Category: Readability Rules

Here's a similar StackOverflow question on the same topic.

ParmesanCodice
+1  A: 

I usually access parameters on the current object with this. Given a naming convention for instance variables "m_", this makes it easy to see at a glance what is affected by following statements without knowing their context:

m_Height += 10;    // an instance variable
height += 10;      // a local variable
this.Height += 10; // a property
Paul Williams
This is better done by using "this." for all members. And use lower case for instance variables, to clarify which are different. Instance varible: this.height. Local: height. Property: this.Height.
Kevin Albrecht
I agree with Kevin, I'm not a fan of the "m_" convention/
ParmesanCodice
To each his own. m_height is shorter than this.height. Our dev group decided having instance fields use different names than local variables was a good thing. In other words, in a constructor, we use `m_height = height` instead of `this.height = height`. /shrug
Paul Williams
+3  A: 

I would say avoid as much as possible, it saves you some(in fact a lot of) typing.

I would depend on Visual Studio more to help me to find where what belongs(never forget F12). I don't use notepad to read my cs files :P

System.ArgumentException
A: 

Our coding standards at work state that member variables shouldn't be prefixed with 'm' or'_' or whatever else most people use. I've actually found myself using this.memberVariable all the time. I prefer the clarity over a little extra typing. And as mentioned in other answers, it's necessary when referencing parameters with the same name as member variables.

RichK
A: 

If you're using Visual Studio and Intellisense. When you type this you get a list of just your class level variables methods etc. Leaving out all the other possible items.

Frenchie