The codebase I'm working in now has the convention of using private fields and public properties. For example, most classes have their members defined like this:
// Fields
private double _foo;
private double _bar;
private double _baz;
// Properties
public double Foo
{
get{ return _foo; }
set{ _foo = value; }
}
public double Bar
{
get{ return _bar; }
set{ _bar = value; }
}
public double Baz
{
get{ return _baz; }
}
I know these can be rewritten without their internal private properties:
public double Foo{ get; set; }
public double Bar{ get; set; }
public double Baz{ get; private set; }
I'd like some input on this:
- Is there a good reason to prefer the older, more explicit style over the
newer, more concise one? - Should I write any new classes using the
concise style, or should I try to match the older code for
consistency? Is consistency worth enough in this case to justify the older format?
Best Answer
There are a couple instances where the so-called "older" style is still required:
A: Immutable types using language-provided immutability. The
readonly
modifier in C# freezes that value after construction. There's no way to mimic this with automatically-implemented properties (yet).B: Your getters/setters have any logic whatsoever. WPF and Silverlight (and similar) code that are data-bound to your classes will implement
INotifyPropertyChanged
like so:Other than those, I'd say use the new style. Keeps your code concise and offers less surface area for bugs to creep in. Plus, if it ever needs to change to include logic, it won't be signature-incompatible.