It is best practice to use .NET properties instead of fields.

Previously, we saw 6 cases in which properties should be avoided. A natural progression of thought may be:

Why don’t we just always avoid properties?

To understand this, we must first understand what properties are, and what they are good for.

What are properties?

Properties are language features found in certain programming languages. For example, C++ and Java do not support properties, while Python and C# do. For C#, property usage is documented in detail on MSDN.

Fundamentally, properties are a special kind of class member, intermediate between member code (methods) and member data (fields). Property reads/writes look syntactically the same as field reads/writes, but property reads/writes are usually translated to accessor method calls. The field-like syntax is more intuitive to program than method calls, yet the interposition of method calls allows for data validation, active updating, read-only “fields”, etc.

In other words, properties offer better usability than methods, and stronger encapsulation than fields.

When to think twice about using properties?

To avoid unnecessarily complicating the source code, think twice before using properties over fields when properties do not encapsulate anything meaningful.

There are situations in which properties may be preferred even if they do not encapsulate anything meaningful:

  • 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.

Possibly in response to community discussions like the one started by Jeff Atwood, Microsoft introduced auto-implemented properties in C# 3.0. Auto-implemented properties are useful and usable, therefore should always be considered when designing new classes.

For more in-depth coverage on this subject, check out Jon Skeet’s article on why properties matter.