The Pragmatic Programmer

It is because it achieves the concept of Encapsulation. If, for instance, in the future you need to introduce a validation logic when setting or getting a value, you can add it at the property body without the need to change signatures.

This process is transparent to the client code, therefore, easier to maintain.

Imagine if you need to introduce this validation logic to every client code that accesses the public field? How many code needs recompiled?

Then it would depend on how much people is using the code. If you're the single developer with no expectation of changing ownership soon (e.g. your own private app), you're definitely free on using anything.

But if there is two or more people sharing the code, it would be easier and safer to code a public property than a public field.

And since it's .NET, technically everyone can use your code, so it's still better to use property for security purposes.

Of course, if this is just a prototype or throwaway code, no coding style would be needed.

The number of people definitely requires attention. Properties provide managed access point towards internal data structure.

Safer: say you need an age data from a person. If you expose this data using public field, then everyone can read/write to it. This is not the case when you're using a property, read/write operation can be controlled, e.g. public has read but write only protected.

Easier: you can change the code inside the property without affecting users of the property. If, for some reason, you need to change how the age is calculated (maybe from code logic to sql logic), you can change it without affecting the users of the property. You can't achieve this in fields, assuming that fields cannot have any logic embedded.

Slower: yes, but by how much? If you take a look at .NET class hierarchies, you can find classes that inherits many abstract classes without affecting performance. Polymorphism performance have been very improved that you won't notice the difference.

If you don't mind that people can take a look and change your internal data (like maybe in the case of dumb data holder classes), then public fields is a go. But most of the time, this approach should be avoided. Not wrong, but just not preferred (for the reasons stated above).

Oh, and one more thing, you can put property declaration in interface, thus making it a contract. You can't do this with fields. (.NET interface assumes that fields should be internal to the class)

As Adrian said, the reason is to achieve OO Encapsulation. OO mandate that fields should be encapsulated. Then "Getter" and "Setter" method must be defined to access/change the field.

If we want the client to do access only for the field, and not give client rights to set the field, we simply create a "Getter method, without the "Setter" method.

Other scenario, we may allow derived classes to set the field. We can simply create the "Setter" as "protected" and not "public".

In C++ or Java, "Getter" and "Setter" are literally methods. In C#, we have Property, but really, it is also a method (see the IL). So, Property is just convinient way for "Getter" and "Setter". But it's also a method. It's just a C# syntactic sugar!

If you don't care about access rights of fields, you can always do public fields, without getters and setters. If you don't have code (validations, etc) that you want to add like in "Getter" or "Setter", fine, you can use public fields. Besides, you can always refactor them to getters & setters (property).

But, there's not a bad thing too if we create the getters & setters. It's also a matter of uniform style to access fields.

Cos the reason to stick with public fields is not really a strong case...

The performance thing, it's trivial. It's just stfld vs callvirt. Performance overhead of "Getters" and "Setters" are trivial and can be ignored. It's microoptimization.

The writing code thing, today we have code gen. Spitting a public field or a property is also trivial.

The argument I see isn't to do away with Properties and encapsulation, but rather to do away with trivial Properties that do nothing more than pass through to the underlying field. If in the distant future I might need to refactor a field into a property, I will then worry about binary compatibility. If I don’t need to worry about it, then use a public field in lieu of a trivial property.