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.

What others have said

Requesting Gravatar... Scott Mar 25, 2005 2:15 AM
# re: Tried of Typing C# Properties?
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
Requesting Gravatar... Tyler Mar 25, 2005 9:41 AM
# re: Tried of Typing C# Properties?
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.

Requesting Gravatar... Haacked Mar 26, 2005 5:39 AM
# re: Tried of Typing C# Properties?
"Capitalized Camel Case" is called "Pascal Cased".
Requesting Gravatar... fortyseventeen Jan 20, 2007 5:12 AM
# re: Tried of Typing C# Properties?
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.

What do you have to say?

(will show your gravatar)
Please add 6 and 2 and type the answer here: