Are there any reasons not to use "this" ("Self", "Me", ...)?

Question

I read this answer and its comments and I'm curious: Are there any reasons for not using this / Self / Me ?

BTW: I'm sorry if this has been asked before, it seems that it is impossible to search for the word this on SO.

Answer 1

It was asked before indeed, in the "variable in java" context:

Do you prefix your instance variable with ‘this’ in java ?

The main recurrent reason seems to be:

"it increases the visual noise you need to sift through to find the meaning of the code."

Readability, in other word... which I do not buy, I find this. very useful.

Answer 2

That sounds like nonsense to me. Using 'this' can make the code nicer, and I can see no problems with it. Policies like that is stupid (at least when you don't even tell people why they are in place).

Answer 3

Warning: Purely subjective answer below.

I think the best "reason" for not using this/self/me is brevity. If it's already a member variable/function then why redundantly add the prefix?

Personally I avoid the use of this/self/me unless it's necessary to disambiguate a particular expression for the compiler. Many people disagree with this but I haven't ever had it be a real sticking point in any group I've worked for.

Answer 4

I think most of the common scenarios have been covered in the two posts already cited; mainly brevity and redundancy vs clarity - a minor addition: in C#, it is required to use "this" in order to access an "extension method" for the current type - i.e.

this.Foo();

where Foo() is declared externally as:

public static void Foo(this SomeType obj) {...}

Answer 5

as for me i use this to call methods of an instantiated object whereas self is for a static method

Answer 6

It clarifies in some instances, like this example in c#:

public class SomeClass
{
    private string stringvar = "";

    public SomeClass(string stringvar)
    {
        this.stringvar = stringvar;
    }
}

Answer 7

I think this is a non-issue, because it only adds more readability to the code which is a good thing.

For some languages, like PHP, it is even mandatory to prefix with $this-> if you need to use class fields or methods.

I don't like the fact that it makes some lines unnecessarily longer than they could be, if PHP had some way to reference class members without it.

Answer 8

In the end it's always a matter of personal choice. Personally, I use this coding convention:

public class Foo
{
  public string Bar
  {
    get
    {
      return this.bar;
    }
    /*set
    {
      this.bar = value;
    }*/
  }
  private readonly string bar;

  public Foo(string bar)
  {
    this.bar = bar;
  }
}

So for me "this" is actually necessary to keep the constructor readable.

Edit: the exact same example has been posted by "sinje" while I was writing the code above.

Answer 9

I personally find that this.whatever is less readable. You may not notice the difference in a 2-line method, but wait until you get this.variable and this.othervariable everywhere in a class.

Furthermore, I think that use of this. was found as a replacement for a part of the much hated Hungarian notation. Some people out there found out that it's still clearer for the reader to see that a variable is a class member, and this. did the trick. But why fool ourselves and not use the plain old "m_" or simply "_" for that, if we need the extra clarity? It's 5 characters vs. 2 (or even 1). Less typing, same result.

Having said that, the choice of style is still a matter of personal preference. It's hard to convince somebody used to read code in a certain way that is useful to change it.

Answer 10

well, eclipse does color fields, arguments and local variables in different colors, so at least working in eclipse environment there is no need to syntactically distinguish fields in order to specially mark them as "fields" for yourself and generations to come.

Answer 11

'this.' in code always suggests to me that the coder has used intellisense (or other IDE equivalents) to do their heavy lifting.

I am certainly guilty of this, however I do, for purely vanity reasons, remove them afterwards.

The only other reasons I use them are to qualify an ambiguous variable (bad practice) or build an extension method

Qualifying a variable

string name; //should use something like _name or m_name

public void SetName(string name)
{
     this.name = name;
}

Answer 12

In VB.NET one of the common practice I use is the following code :

Class Test
    Private IntVar AS Integer
    Public Function New(intVar As Integer)
       Me.Intvar = intvar
    End Function    
End Class

Not all the time but mostly Me / this / self is quite useful. Clarifies the scope that you are talking.

Answer 13

If you use StyleCop with all the rules on, it makes you put the this. in. Since I started using it I find my code is more readable, but that's personal preference.

Answer 14

In a typical setter method (taken from lagerdalek's answer):

string name;

public void SetName(string name)
{
     this.name = name;
}

If you didn't use it, the compiler wouldn't know you were referring to the member variable.
The use of this. is to tell the compiler that you need to access a member variable - which is out of the immediate scope of the method. Creating a variable within a method which is the same name as a member variable is perfectly legal, just like overriding a method in a class which has extended another class is perfectly legal.
However, if you still need to use the super class's method, you use super. In my opinion using this. is no worse than using super. and allows the programmer more flexibility in their code.

As far as I'm concerned readability doesn't even come into it, it's all about accessibility of your variables.

Answer 15

Not only do I frequently use "this". I sometimes use "that".

class Foo
{
    private string bar;

    public int Compare(Foo that)
    {
        if(this.bar == that.bar)
        {
            ...

And so on. "That" in my code usually means another instance of the same class.