views:

631

answers:

15

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.

+1  A: 

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.

VonC
+1  A: 

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).

Torbjørn
+8  A: 

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.

JaredPar
Subjective comment: Using this reason, do you also remove line breaks in your code? You should write code to be human readable first, then machine readable as a second priority.
Torbjørn
@Torbjørn: What if he finds omitting this/self/me more human readable?
Firas Assaad
I do find it more human readable. I prefix member variables with m_/_ and I find reading this.m_foo to be no more readable than m_foo. m_ means member so why add the additional baggage?
JaredPar
Then it's perfectly fine. That's not how I understood his answer though.
Torbjørn
Don't misunderstand me, I almost never use "this", but I would oppose a policy preventing me from using it!
Torbjørn
agree, it's all about disambiguation, so only use it when there's possible ambiguity. Less code is always better code. Well, except when it isn't.
Jeff Atwood
@JaredPar: prefixing with "m_" is already achieving the same result as "this." in readability terms, the comparison should be between "this.foo" and "m_foo" and imho the former is clearer and more elegant. Also note some languages have the ability to say "with (this)" which is just... *beautiful* :)
annakata
... until you move the code and the with introduces ambiguity, at which point ot becomes a beautiful nightmare... :) It always depends.
Mihai Limbășan
+8  A: 

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) {...}
Marc Gravell
A: 

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

ken
In which language?
DR
PHP, this is also true for java but instead of self, the classname itself is the prefix
ken
+4  A: 

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

public class SomeClass
{
    private string stringvar = "";

    public SomeClass(string stringvar)
    {
        this.stringvar = stringvar;
    }
}
sindre j
But wouldn't that be a reason to use it? (And not NOT to use it?)
DR
It would be a reason to rename the parameter ;)
boutta
I agree, the parameter should be renamed :) But it still shows how this. helps to understand that it's the class private variable and not the parameter beeing referenced.@daniel: Yes, that was my point. In this example it would make good sense to use this.
sindre j
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 a method.
James Camfield
+2  A: 

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.

Franck
A: 

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.

a setter for a "readonly" field... Uh oh.
Johan Buret
Thanks, commented the setter. I don't this do in real life though, just a small brain error while thinking of an example ;-) However, it's not really the issue here - the example is about the line "this.bar = bar".
+2  A: 

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.

Dan C.
I would count "m_" as 5 finger-movements :)1) 'm'2) <shift>3) '_'4) return left finger to home keys5) return right finger to home keysI might even find myself typing "this." faster than "m_". :DAnd it has the advantage of invoking intellisense in IDEs other than Visual Studio.
Hosam Aly
You're right about finger movements. I personally prefer using plain _, which is shorter.Speaking of which: I remember a nice Visual Assist feature from the good ol' C++ days - typing "m" then "shift" would automatically insert "m_".
Dan C.
+1  A: 

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.

miceuz
+1  A: 

'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;
}
johnc
A: 

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.

dr. evil
+3  A: 

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.

DeletedAccount
A: 

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.

James Camfield
A: 

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.

Guge