Do you use 'this' in front of instance var

Question

When accessing instance variables or properties of a class from within the class itself, do you prepend them with "this."?

Answer 1

It adds clutter. So no.

Answer 2

In C#, I absolutely do. The primary reasons are:

1. Whether to do it or not is a stylistic issue. In spite of all the fighting that goes on, I don't believe there's an objectively better approach.

2. My source analysis tool (StyleCop) defaults to requiring this. in front of instance accesses. My first point implies that I shouldn't care much about whether I always do or always don't, and because the default StyleCop setting is to always require it, I take the path of least resistance/greatest consistency and I follow the default setting.

I follow this philosophy for most stylistic issues. I'm a huge fan of not changing default formatting options in an auto-formatting IDE. It just makes everyone's life harder over something that's really just not that important.

Answer 3

I think this practice improves legibility most of the time, so yes.

Answer 4

No. I consider it visual noise. I think the this variable is a crutch to bad naming styles. Within my type I should be able to manage the naming of the fields, properties and methods.

There is absolutely no good reason to name your backing field "myfield", the parameter to the constructor as "myField" and the property to be "myField".

 public class TestClass
 {
    private string myField;
    public TestClass(string myField)
    {
      this.myField = myField;
    }
    public string MyField {get { return myField;} set {myField = value}}
 }

Personally, I always add a prefix of _ to all my private backing fields.

 public class TestClass
 {
    private string _myField;
    public TestClass(string myField)
    {
      _myField = myField;
    }
    public string MyField {get { return _myField;} set {_myField = value}}
 }

and now with automatic properties in C#

 public class TestClass
 {
    private string MyField {get; set;}
    public TestClass(string myField)
    {
      MyField = myField;
    }
 }

Other than the above maybe the only other time you type this. is because you want to see the intellisense for your current type. If you need to do this then I submit that your type is too big and probably not following the Single Responsibility Principle. And lets say you are. Why keep the this. around after you actually make the call. Refactor it out.

Answer 5

Absolutely. 'this' avoids the need for any prefixes, such as m_. More importantly, it quickly improves the performance of my code, and this is why:

I've really embraced the Microsoft Cops (FxCop, StyleCop). They've really helped me to catch things that normally I wouldn't even think about. For example, if a method does not reference any member variables, one suggestion from FxCop is to mark the method as static, so the method doesn't have to be allocated to every instance of the class. From MSDN:

Methods that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

Prefixing my member variables with 'this.' does two things for me. First, it satisfies StyleCop. Secondly, and more importantly, it helps me to quickly identify if a method needs to be marked static.

Of course, running FxCop will tell me if I need to mark a method as static. However, using 'this.' helps me spend more time writing new code and less time remedying FxCop violations.

Answer 6

I do, for me it adds a bit of clarity to the code, is it in the current procedure or the class?