Use of this

[klintan]

I was just wondering about your opinion on using this. Personally I prefer to omit the this operator unless really needed, but I see that some people like to use it all the time. I have once learnt to write as little code as possible, I think it makes the code easier to read.

With this:

public class Form1: Form
{
   private int _someInt;
   private int someMethod() { ... }

   private void anotherMethod()
   {
       this._someInt=this.someMethod();
       this.DialogResult=DialogResult.OK;
   }
...
} 

Without this:

public class Form1: Form
{
   private int _someInt;
   private int someMethod() { ... }

   private void anotherMethod()
   {
       _someInt=someMethod();
       DialogResult=DialogResult.OK;
   }
...
} 

[jhammer]

I don't use "this" either, unless a parameter or a local variable has a similar name as one of my members (I use _ before the names of my members, so it is almost always not necessary at all to use "this").
I will only use "this" if makes my code more readable (absolutely subjective on my part).

BTW, the use of DialogResult in your code will generate a warning in 2005 (at least in VB) because a property has the same name as an Enum. In this case I will use both "this" and the full namespace (and eliminate the warning).

[creatorul]

Use this when you need to make difference between variables:

public class Form1: Form 
{ 
   private int _someInt; 


   private void anotherMethod(int _someInt) 
   { 
       this._someInt=_someInt;
 
   } 
... 
}

Use it when you need to emphazise the belonging to your class of that variable. I suggest to use it only when you need it ( to increase readability and decrease the amount of code), like the situation above.

[boudino]

I strictly use this everywhere. The code is not only for compiler, but also for a devloper. If you use this, other developers looking at your code can simply recognize that you are working with the instance member, not with e.g. static member. I have learned this approach in Smalltalk, where self (similar to this) was mandatory and I find using this helpful.

For me, it is harder to navigate in and read code without this, because you have to pay extra attention to the context of the identifier. I think that omiting this is a sign of lazy developer (like naming fields sum1,sum2 (or worse a,b) instead of sumWithTaxes and sumWithoutTaxes).

[Shuja Ali]

I would also use this wherever it is required as posted by boudino. Like in Post #1 the first code snippet is much easier to read for a new developer than the second one.

So I would advocate for using this for all instance members.

[exterminator]

I won't. You can do a this.staticMember too - which can be very confusing. Moreover, what I feel is unless a person knows the meaning of a member be it an instance member of a static member - he/she should not go ahead with coding. Understanding the members and their physical meaning is the first thing to do.

I see one example above where the argument name is same as the member name - I think that naming convention is bad in itself - that should be avoided and hence the usage of this is not required.

Regarding readability - anything that is not associated with someother object would be something that belong to the class that the code is presently it. That should be self explanatory. If something does not belong to "this" then it will of course be written in association with the object or class that it belongs to.

"this" should not be used for above scenarios - but one place where I think its usage is justified is - when passing the object itself to someother class member or anywhere outside the class it relates to.

Personal opinion, of course.

[Shuja Ali]

I won't. You can do a this.staticMember too - which can be very confusing.

this cannot be used with a static member. It will generate a Compile Error.

	public class Class1
	{
		public static string name;
		public void test()
		{
			//static member cannot be accessed with an instance reference
			this.name = "Hello";
		}
	}

[Dmorley]

I actually use this a lot just to get at the intellisense for all my variables etc ! Why type them out when the IDE is happy to do it for you?!

Personally, I think if you are extending a class or are designing a class that could be extended in future, it's good practice to clarify the scope of everything.

If it's a sealed class that doesn't inherit anything, I may omit this here & there, it's definitely self explanatory.

[exterminator]

Thanks Shuja for correcting me! A C++ hangover that was! But still rest of my arguments stay.

Dmorley - are you saying that the inherited members would not be shown by intellisense when you use this?

[Dmorley]

Nope, inherited members will still be shown - depends on the access modifiers they've been declared with.

My point is in an inheritence scenario, I just prefer the scope clarity that using this provides. Like you said, scope is often obvious....but it doesn't hurt to use!

[cjard]

I strictly use this everywhere. The code is not only for compiler, but also for a devloper. If you use this, other developers looking at your code can simply recognize that you are working with the instance member, not with e.g. static member.

In java we name our classes with caps to start, and our instances with lowercase..

myForm1.Show() //instance
MessageBox.Show() //static

If you follow this convention, (microsoft seem to as all instances created in the visual side are lowercased to start.. textbox1, button1.
In vb.net they are uppercased: Textbox1, Button1 but then, vb is not for precise people)

For me, it is harder to navigate in and read code without this, because you have to pay extra attention to the context of the identifier. I think that omiting this is a sign of lazy developer (like naming fields sum1,sum2 (or worse a,b) instead of sumWithTaxes and sumWithoutTaxes).

Its a personal preference thing.. I find that copious use of "this" adds clutter to the code and makes it unreadable

My rules for using it tend to be where there is no named instance to use. consider a form with one button:

BackColor = Color.White
this.BackColor = Color.White //i use this notation
button1.BackColor = Color.White //i use this notation
this.button1.BackColor = ColorWhite

so i guess you could say i like to put exactly one period before setting a property, and in cases where im setting a property of the current object, it requeres a "this"

I dont go for sitatuons where i have a class wide variable and a method scoped variable with the same name - the english language is suitably varied for me not to have this potential bug-waiting-to-happen in code.

i also use this to refer to the current object rather thana parent, in an inheritance hierarachy.. but again, i try to avoid hiding parent fuinctionality if possible so i do not need to use this. or base. to differentiate between which block of code will run for members that hide other members