A warning to the non-technical, this is going to get technical.

While I’m sure they weren’t the first language to do so, C# made properties first class supported constructs and I thank them for it daily. Previously, or currently in other languages, this was often accomplished through accessor methods, typically named something like GetValue(). You can then protect your variable, or add more logic, through this technique. If you’re lost at this point then try this and this.

l was asked today “do you find it weird to use a public property to access something from inside the class where that property exists?” To elaborate, and take it one step further, in example. We have a class named Person. We have a private integer variable in the Person class named _bodyHair and, well I’ll leave it to your imagination what we’re storing in that variable. You’re writing some code in the Person class, if you had to access that private variable _bodyHair how would you do it?

Would you access the variable directly or would you create, and use a property, or accessor method? In the early stages of a class, accessing the variable directly is simplest and most obvious. It may even seem a tad bonkers to create an essentially empty private property and add the performance overhead of the added calls.

I do just that almost 100% of the time. Why? My primary reason for doing anything is that I’ve been burned by not doing it a lot in the past. In this case I’ve been burned by accessing a variable directly and then down the road having a bug related to it’s return values. Something like null being returned when we want -1. So I refactor the class, add a property containing that logic. I’m then left refactoring all references to that variable over to the new accessor property. Annoying but not a big deal.

Burn #2. I’ve spent days, possibly weeks, chasing down a particular species of bug. It’s a simple one. A developer accesses a variable directly instead of through it’s property. In the above example, doing so allows that null value to trickle up the chain and get it’s nose into business a -1 wouldn’t have. Not a big deal, just lost time.

Let’s get crazy and contemplate if there’s a way to reduce the odds of generating a bug like this again? I realize this isn’t anyone’s job and we’re probably messing with the very fabric of corporate software development but humour me. The problem is accessing a private variable directly in the class you’re working in. It’s easy to miss the fact that a private property for that variable exists and thus miss the logic you need. There’s no way to make a variable extra private to prevent access from anywhere outside of your property. Typically the rule is to go ahead and access the variable directly unless a property has been defined. It’s the float in that rule that allows for the burn #2 bug.

So why not just move all access to properties? Doing so eliminates, or at least reduces, the chances of human error. I have been doing this myself for years. I rarely, if ever, access a variable directly even within the class it exists. I use properties for almost all variable access. This makes it simple to add any required access related logic down the road as well as greatly reducing the risk of a relatively common bug. It does introduce a potential performance issue in the added calls and means more code. I tend to err on the side of simple code and reducing the chances of bugs. Am I nuts??

This entry was posted on Wednesday, August 30th, 2006 at 6:36 pm and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.