Q: What do properties buy you?
A: The most oft quoted benefit is as follows: You can start with public member variables, and at a later stage in your development process if you decide that you need to do some processing whenever the variable is read or written you can do so by changing the public member variable into a property.

Q: Why doesn't that work in practice?
A: In reality, if you change a public member variable to a property you have no guarantee that you will not break client code. For example, this code will not compile if you change Sum to a property:

public void Test() {   Foo(ref bar.Sum); }

Q: Do properties have any other benefits?
A: Properties have a cleaner syntax because you don't have to supply the parenthesis.

Q: Does omitting the parenthesis make the syntax cleaner?
A: Yes, if "cleaner" to you is fewer characters on the screen. No, if "cleaner" to you is something that appeals to the sense of logic and reason.

It should be noted that Pascal did not require you to supply the parenthesis when you call a function, if that function takes no parameters. C requires you to supply the parenthesis even if the function takes no parameters. Many people think C is cleaner in this regard because it makes logical sense to require the parenthesis.

Q: What case convention should I follow when naming properties?
A: Private member names should begin with a lowercase letter while other member names should begin with an uppercase letter.

It should be noted that while this is a good convention to follow while writing code, it is only a convention, and is not enforced by the compiler. Hence it is not a good idea to rely on this convention while reading code.

Sample code included with the .NET SDK does not always adhere to this convention (see portal example). Also, some tools (such as xsd) generate code which has wrong case properties.

Q: How can using properties cause me to miss inefficiencies?
A: Quick, can you spot the inefficiency in this code?

public void Calc(int[] foo) {   Sum = 0;   for (int i = 0; i < foo.Length; i++)     Sum += foo[i]; }

What you may have missed is that every += involves two function calls. The only indication of this fact is the uppercase 'S' in Sum (which by the way is a convention that is frequently not followed), so the inefficiency is not easy to spot.

Now consider this variation of the same code:

public void Calc(int[] foo) {   Sum = 0;   for (int i = 0; i < foo.Length; i++)     SetSum(GetSum() + foo[i]); }

Now the inefficiency is glaringly obvious, so you may rewrite it like this:

public void Calc(int[] foo) {   int temp = 0;   for (int i = 0; i < foo.Length; i++)     temp += foo[i];   SetSum(temp); }

If getting or setting sum is not cheap (now or in the future), the resulting improvement in performance may be nothing to sneeze at.

Code that uses properties gives you no immediate feedback on the compactness and efficiency of the code.

Q: Are there any other pitfalls I should be aware of?
A: Quick, can you spot the database access in this code?

public int CalculateRaise(int percent) {   return (salary + bonus + Commission) * percent / 100; }

If you missed the uppercase 'C' in Commission you missed the database access. (Database access in a property getter is not uncommon.) Be sure to choose a good font when reading code — one in which uppercase C looks very different from lowercase c. Better still, rewrite your code like this, so you can clearly see the function call:

public int CalculateRaise(int percent) {   return (salary + bonus + GetCommission()) * percent / 100; }

Q: What can we conclude from all this?
A: Properties buy very little when weighed against the problems its use is likely to cause.

[Back to Index]