Treasure

Treasure

When a man assumes a public trust, he should consider himself as public property.
Thomas Jefferson

In my previous blog post, I talked about Naming Conventions.  I was concerned about the apparent “purity” on paper with the cumbersome “workability” of unnecessarily restrictive Naming Conventions.

I have the same concerns with Properties.  Well defined guidelines for Properties can make IntelliSense a helpful tool and coding typos can be more easily discovered by the compiler.

First, let’s answer the question, why use properties instead of fields in a class?

  1. A field has the same access for read/write.  A property can have public read and private write.
  2. A property can validate before data assignment.
  3. A property data read can gather/combine pieces of other data to get a result.  For instance, a property named IsReady can check many instance properties/fields before returning true or false.

Properties are wordy compared to a field definition.  In Visual Studio, I can type prop followed by two tabs and I will see something like the following.

This is still cumbersome to change the int to my required data type, change the name of the backing field myVar and then change the name of MyProperty.  Even with snippets, this property was tedious.  Why not just use fields?

Matter of fact, a field named MyField will show up only once in IntelliSense where as this example will show up twice, myVar and MyProperty.  Then, our old friend Naming Conventions gives us rules for the name of myVar.

Most of the Naming Conventions I have seen tell us NOT to use a prefix and seem to imply name should be the same as the property name except starting with a lower case letter.  This is not a viable answer for case insensitive languages like VB.Net.  Later in this article, I will this naming approach is not the best approach in C# either.

To fix the property which is just simple access control to a field, Microsoft changed the prop snippet in Visual Studio 2008.  This solves the problem and only one entry shows in IntelliSense.  It also forces the good practice of only accessing the property NOT the backing field.

As good as this snippet is, we still need a full property snippet which is now missing in VS 2008.  Before I get to showing my full property snippet, I want to complete the argument for my Property Naming Convention.

Many Naming Conventions suggest the following for MyProperty.

  1. Back field same name as property except start with lower case letter.
  2. Suggest using “this” or “Me” to distinguish between property and backing field.

In VS 2005, this typo would give no warning.  At least in VS 2008, there is a warning.  Regardless of IDE, I consider this bad practice.  The backing field should only be used inside the setter and getter methods.

I use an underscore prefix for my backing field.  This alleviates the possible confusion due to variable name and backing field name having the same name inside the constructor.  Also, IntelliSense is clear.  When I type the first few letters of my property, I only see properties, no backing fields.  The simple class shows this below.

What if I need access to the backing field, IntelliSense is again my friend.  I just type “_” and the first couple of letters of the property.  IntelliSense takes me right to the backing field.  Since I am inside either the setter or getter of the property, there is never any confusion about which back field I am using.

Lastly, my full property snippet becomes easier.  I only need to enter two pieces of information(type and name) just like the new prop snippet in VS 2008.

The code for my prop snippet is shown below.  A snippet file is really just an XML file with an extension of *.snippet  Any text editor that understands XML will do.  My favorite Windows Text Editor is NotePad++.

Download my Snippets

Tags:

Leave a Reply


*