The semantic difference between a property and a field, and their implications

Question

Take private string Property {get; set;} versus private string field.

Note that both are private (so they will not be exposed outside of this class) and that the property is not employing extra validation.

As regards semantics, do they have different meanings? In the sense that, are they interchangeable when used like this?

And when it comes to implications, such as (micro?) performance, does it matter if you create a field versus a property i.e. letting the compiler take care of the backing field for you.

Answer 1

When they're private the only difference I know is that the property is not suitable for out and ref parameters.

But mostly a private property does not deliver any advantages (over a field), so why bother?
There probably are (micro) performance costs. I would worry more about the extra clutter.

Answer 2

• A property is about data hiding of a field
• A private property does not mean much, since whoever has access to the property, will have access to the field as well
• There is no performance implication for auto-property versus backing field since compiler spits out the backing field but there can be serialisation/deserialisation caveats.

---

UPDATE

Performance implications:

There is a slight performance in using property (auto or with backing field) vs field since a property is a method and a CLR virtcall needs to be called.

But as I said, there is not much point in using property and I believe a field is more readable as usually immediately visible by the naming convention (starting with underscore or camel casing).

Answer 3

You can't have a reference to a property, but you can get a reference to a member. Thus, if you use members, you might have trouble switching them to properties for whatever reason later, such as adding the notorious validation.