Every workplace has a different coding “standard” (which are often more like guidelines than set rules) and adjusting to different standards can be difficult, especially since I have been coding mostly for myself for the past year. However, sometimes standards are a little illuminating into the languages you are working with. One small topic I have been wrestling with is C# members vs. properties.

In an attempt to keep myself out of trouble, I will avoid using the definitions used in the coding standard I am currently trying to adhere to at work. However, the definitions are quite simple and easy to understand. Instead, I’ll have to settle with the definitions from Microsoft’s library. I am also using members/properties in the context of variables or fields rather than methods.

Both members and properties are class-level variables. Meaning, they exist outside of any method, but within the wrapper of the class. Take for example:

public class MyClass
{
	private string myField;
	private string yourField;
}

myField and yourField are simple class members/fields. General OOP convention is to make these members/fields private for encapsulation purposes.

What differentiates a property from a member is that a property has public Get/Set methods:

public class MyClass
{
	private string myField;
	private string yourField;
	
	public string MyField {
		get { return myField; }
		set { myField = value; }
	}
	
	public string YourField {
		get { return yourField; }
		set { yourField = value; }
	}
}

MyField and YourField (note the Pascal casing for .NET conventions indicate that these are methods rather than variables) can be called by anyone, but the variables they reference cannot. Indeed, the way these getters and setters are currently coded is the equivalent of making the private variables public. But suppose I wanted to do the following:

public string MyField {
	get { return myField; }
	set { myField = value + "\'s field"; }
}

And then,

MyClass mc = new MyClass();
mc.MyField = "Khatharsis";
Response.Write(mc.MyField);		// Outputs "Khatharsis's field"

The main purpose of having properties is to provide this kind of encapsulation. .NET just has a different notation that is supposed to make it easier for developers who are familiar with good OOP practices.

The main thing I have been trying to figure out (as I still have not yet been able to see any existing code from other projects) is how to properly use the this keyword with members/properties. My convention is to use this when I am initializing the private members within a constructor, e.g.,:

// Constructor method for MyClass
public MyClass() {
	this.myField = "";
	this.yourField = "";
}

Which could just as easily be done using the properties like:

public MyClass() {
	MyField = "";
	YourField = "";
}

Or even like:

public MyClass() {
	this.MyField = "";
	this.YourField = "";
}

What makes this scenario even more confusing is when I have a class method and I want to use the class member – which do I use to help others reading my code understand I am using a class member and not some random, seemingly undeclared, uninitialized variable?

public void AnExcellentMethod()
{
	Response.Write(this.myField);	// class member with this keyword
	Response.Write(MyField);		// property
	Response.Write(this.MyField);	// property with this keyword
}

As far as I can tell from browsing various StackOverflow pages and other articles, there’s a lot of opinion regarding which practice is preferred. Ultimately it seems to come down to workplace standards and personal preference. One definite must-use of the this keyword is when a method parameter has the same name as a class member. this will point to the class member to make it clear which is which.

Building on that, for me, it makes more sense to use this.myField. If it is already being used to get around parameter shadowing, why not keep that convention everywhere class members are being referenced? The class methods have access to the class members and it makes it clear that class members are being referenced rather than a local method variable.

True, one drawback is if a future developer (including yourself) forgets the convention and accidentally drops the this keyword. It becomes a little harder to spot because now the variable looks like a normal method variable that seemingly appeared out of nowhere. Yet, using this with the corresponding property also feels a bit like overkill.

I am sure this is one of those tastes that will change over time. But, I thought it was worth pondering on.