Actually, all the guidelines are about creating reusable libraries. There, when you create a property (using get/set), you also create the opportunity to later add code that is executed when someone gets or sets the value (like adding validation etc.) without changing the external definition of your code (and thus not needing to recompile the other libraries). But this has no value if you always recompile your whole solution and noone else is using the library.
Another benefit from using a property is that you can limit who can get or set the value. For example, everyone can get the value but only derived classes can set it (protected).
This said, it is still the recommendation to use properties always when they are public (as opposed to private fields).
I only expose fields when I need the best possible performance (like accessing the value million times in a row).
So to summarize
Benefits of properties (get/set) over fields:
- Ability to add code later on without recompiling assemblies that reference this.
- Ability to provide private/protected/internal set and public get (or any other combination).
- Public fields are not CLS compliant.
Drawbacks of properties:
- Slower to access (both read and write).
- Can't pass as
ref arguments to methods.
