views:

105

answers:

9

On the internet I see a lot of code which uses this. to access local members of a class, like this:

private String _whatever;
public String Whatever
{
  get
  {
    return this._whatever;
  }
  set
  {
    this._whatever = value;
  }
}

public void DoSomething()
{
  String s = this.Whatever;
  this.DoSomething();
}

(don't expect the code to do something sensible. I just wanted to show a few different uses for "this.")

I wonder why to do this? To add more clarity to the source?
Or is it just a waste of space?

+7  A: 

It all reduces to personal preference and good practices.

In most situations it just doesn't matter but it might matter when you happen to have a parameter with the same name as a private field (which indicates a bad naming convention anyway).

From my personal point of view, any variable reference to a parameter or a field or almost whatever should be clear enough without the "this" qualifier... only when it is not and you can't change it to make it so, I use this.

Jorge Córdoba
+5  A: 

There is a rule in StyleCop requiring that - people just seem to use it ;)

TomTom
Yes, and there is a Resharper rule that says it is not needed and can be removed - take your pick!
Hans Kesting
I just tell re-sharper to ignore it, let StyleCop win this one ;)
TWith2Sugars
I am not arguing about whether this is a good or a bad rule - just that it is there, and i am sure that is why so many people follow it ;)
TomTom
A: 

It is a matter of taste. Some of developers usually this is used to show that referenced object is a internal object of the class. Its just syntatic sugar. Also it depends on some of the naming conventions on the project (e.g. starting each field name with underscore).

Andrew Bezzub
A: 

Each of the programmers that write this to distingish class data can have their own reasons. Sometimes is because they are used to, other times because it was required by the coding standard of the project, perhaps they are using a tool formats code like that...

Also, if you don't make a difference between the member variables and the parameters or local variables, as in your example with the underscore, it is useful. Just a question of style.

yeyeyerman
+2  A: 

IMO:

this._member 

is redundant

whereas

this.Property

is justifiable.

Sky Sanders
+1  A: 

It is done to add clarity, particularly to disambiguate parameters from instance members. Personally, I think that

  • If you are using the convention of putting an underscore in front of private variables, writing this._blah is a waste of space
  • It is superfluous in front of method calls
  • It is debatable whether it makes sense in front of a property access

All in all, it is a matter of personal opinion (although, as with everything else, you should be consistent and agree with your colleagues).

Rune
+3  A: 

Odd, nobody mentions this: it works so well with IntelliSense. Type "this." and a list of valid member names pop up. It didn't take me long to justify that with "well, it makes the scope of the identifier obvious".

Hans Passant
A: 

This is to handle the following possible situation:

private String value;
public String Whatever
{
    get
    {
        return this.value;
    }
    set
    {
        this.value = value;
    }
}

Actually, this. is widely used in situations like in the example below:

struct MyStruct
{
    private int val1;
    private int val2;

    public MyStruct(int val1, int val2)
    {
        this.val1 = val1;
        this.val2 = val2;
    }
}

Using this. whenever possible makes your code clearer and excludes the following possible error:

private int myVar;
private void doSmth(int myVar)
{
    // Some code here ...
    myVar = 5; // Are you sure this is one you want to modify?
    // Some code here ...
}

However this is not a strict rule and probably related to personal coding style.

Zenya
I wouldn't say 'safer' (the compiler can surely handle it or you need a different compiler / language); 'clearer' / 'more legible' sounds more applicable.
Hardryv
I added another example to show what did I mean 'safer'. But I agree to replace 'safer' with 'clearer'.
Zenya
A good compiler should report the ambiguity in the last example with an error. IMO it's 'bad' to use the same name for parameters and members.
Lars
+1  A: 

something to consider:

the compiler won't care, and those of us who work behind you will know exactly what you're about even when we are not familiar with your class structures

Hardryv