I've always been told to encapsulate ANY and ALL properties from a class...
This is right:
private string propertyName;
public string PropertyName
{
get { return propertyName; }
set { propertyName = value; }
}
And this is WRONG
Public string PropertyName;
I can't see where is the need of encapsulation... the first code, for me, is just useless redundant code... there's no need for encapsulation of that field...
So if anyone can justify the encapsulation ON THIS SCENARIO. (I can understand on other scenarios).
For the most part, a public field would be okay in practice. After all, if you later needed to make it read-only from outside, or add behavior to its setter, you could just change it to a property then. So you could make it a public field today, and change it later if you need to. Right?
The thing is, there are some cases where you can't safely change it later:
How important are either of these scenarios? Probably not very. But it's easier to preemptively write
public string PropertyName { get; set; }
than it is to clean up the mess if you do have to change it later.
And there's no performance cost. The JIT compiler will inline the getter and setter anyway. So it costs nothing and gives some benefit; at that point, why not use a property?