Tried of Typing C# Properties?

Saw this post on Consult Utah’s Weblog…

Is anyone else getting tired of writting:
...
private bool _autoAccept;
...
public bool AutoAccept 
{ 
  get {return _autoAccept;} 
  set {_autoAccept = value;} 
} 
I’ve pretty much decided that it is just preferable in these cases to just make the member variable public. I’m am being bad? ;-)

My answer? I think he should be publicly flogged, smeared with tar and feather, and paraded around town in a pink tutu.

Ok, that might be a bit extreme. I don’t really believe that.

I think using a public field is fine in some cases. If the interface is unlikely to change. If you’re not writing library code. etc… If you can easily refactor it later if necessary. I’m not a complete and total purist about this.

Now before you OO purists get on my case, I’d like to point out that I always use full properties because I HATE FxCop warnings in my code. ;) Also, I have a nice little code expansion template in Resharper. I simply type

prop<TAB>

and I get a full expansion of the property, allowing me to fill in the type and private member name. You can see a description here.

Resharper also has an ALT+INSERT shortcut for generating code snippets, but I find my little expansion to be faster for me.

Although I’m not an OO purist nazi, I do think that the encapsulation benefits of properties are worth the trouble, especially when they aren’t much trouble.

Comments

5 responses

Scott • March 24th, 2005
Scott Mitchell has a great article on rolling your own property macro in VS over at 4guysfromrolla.com.

http://aspnet.4guysfromrolla.com/articles/032305-1.aspx

Tyler • March 25th, 2005
Phil,

I think that you're right on all accounts about the benefits of making full properties that encapsulate private fields. And since I started using ReSharper it has been a no-brainer.

Or has it?

I've decided that it's not such a bad thing if it's done in such a way that the field can be replaced with a property later on. Expecially in rapid prototyping, who wants to type a bunch of code out when it's not going to bring any benefit?

Well, if you follow some normal naming convention then you can get around it.

In the normal style, I always name my properties in camel case, with the first letter capitalized. I also name the underlying fields the same thing except w/ the first letter in lower case. FxCop doesn't like that, but I haven't heard an arguyment that I agree with.

Anyways, if I'm feeling lazy about making properties, then I'll just make a public, capitalized, camel-case (is that what it's called?) field.

If I wind up keeping the class, all I have to do is rename the field and make a property with the same name. Just that easy.

Haacked • March 26th, 2005
"Capitalized Camel Case" is called "Pascal Cased".

fortyseventeen • January 20th, 2007
It's true that properties and public fields have identical syntax when used, and that fields have less overhead, but there is one difference between the two formats that may be of importance: if you start to implement a class with public fields and later decide to use properties instead, you'll have to recompile everything that relies on that class. It's probably a minor issue in most cases, but can still cause problems in some cases, such as when working with precompiled libraries.
I think, then, that the issue isn't about preserving encapsulation (since, functionally, there isn't any), but about preserving compatibility between object files. If that isn't an issue, than it's fine to use the cheaper solution.
P.S. It's more commonly called UpperCamelCase.

Nick • August 15th, 2012
In Visual Studio 2010, you can just write the following:
public bool AutoAccept
{
get;
set;
}
And it will allocate a variable for you within the class and you only have to use AutoAccept within your class rather than allocating a variable and setting it and getting it with a get/set parameter.