Properties vs. Public Variables
Why waste everyone's time with a bunch of meaningless just-in-case wrapper code? Start with the simplest thing that works-- a public variable. You can always refactor this later into a property if it turns out additional work needs to be done when the name value is set. If you truly need a property, then use a property. Otherwise, KISS!
Update: As many commenters have pointed out, there are valid reasons to make a trivial property, exactly as depicted above:
- Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.
- You can't databind against a variable.
- Changing a variable to a property is a breaking change.
- Distinguishing public and private using only case is an accident waiting to happen.
The difference between name and Name is subtle at best. I don't want to reopen the whole case sensitivity debate, but using case to distinguish between variables is borderline irresponsible programming. Use a distinction that looks and reads different: m_name, _name. Or maybe eschew prefixes altogether and use fully qualified references: this.name. I don't really care. But please, for the love of all that's holy, don't abuse us with even more meaningless case sensitivity.
- Is it a property or a method?
In this case, we barely have a property. But if you are executing code in a property, make sure you've written a property and not a method. A property should do less work-- a lot less work-- than a method. Properties should be lightweight. If your property incurs significant effort, it should be refactored into an explicit method. Otherwise it's going to feel like an annoying side-effect of setting a property. And if there's any chance at all that code could spawn an hourglass, it definitely should be a method. Conversely, if you have a lot of simple, lightweight methods, maybe they ought to be expressed as properties. Just something to think about.
