C# 3.0 Autoproperties - whats the difference?

Question

Hi in C# 3.0 What's the difference between the following?

public class MyClass
{
    public bool MyProperty;
}

public class MyClass
{
    public bool MyProperty { get; set; }
}

Is it just semantics?

Answer 1

"Just semantics" always seems like a contradiction in terms to me. Yes, it changes the meaning of the code. No, that's not something I'd use the word "just" about.

The first class has a public field. The second class has a public property, backed by a private field. They're not the same thing:

• If you later change the implementation of the property, you maintain binary compatibility. If you change the field to a property, you lose both binary and source compatibility.
• Fields aren't seen by data-binding; properties are
• Field access can't be breakpointed in managed code (AFAIK)
• Exposing a field exposes the implementation of your type - exposing a property just talks about the contract of your type.

See my article about the goodness of properties for slightly more detail on this.

Answer 2

The first one is just a public field, the second one is a so-called automatic property. Automatic properties are changed to regular properties with a backing field by the C# compiler.

Public fields and properties are equal in C# syntax, but they are different in IL (read this on a German forum recently, can't give you the source, sorry).

Matthias

Answer 3

In that case, yes it is mostly semantics. It makes a difference for reflection and so forth.

However, if you want to make a change so that when MyProperty is set you fire an event for example you can easily modify the latter to do that. The former you can't. You can also specify the latter in an interface.

As there is so little difference but several potential advantages to going down the property route, I figure that you should always go down the property route.

Answer 4

Fields and properties have many differences other than semantic.

1. Properties can be overridden to provide different implementations in descendants.
2. Properties can help alleviate versioning problems. I.e. Changing a field to a property in a library requires a recompile of anything depending on that library.
3. Properties can have different accessibility for the getter and setter.

Answer 5

The biggest difference is that you can add access modifiers to properties, for example like this

public class MyClass
{
    public bool MyProperty { get; protected set; }
}

For access to the CLR fields and properties are different too. So if you have a field and you want to change it to a property later (for example when you want to add code to the setter) the interface will change, you will need to recompile all code accessing that field. With an Autoproperty you don't have this problem.

Answer 6

I am assuming you are not writing code that will be called by 3rd party developers that can’t recompile their code when you change your code. (E.g. that you don’t work for Microsoft writing the .Net framework it’s self, or DevExpress writing a control toolkip). Remember that Microsoft’s .NET framework coding standard is for the people writing the framework and tries to avoid a lot of problems that are not even issues if you are not writing a framework for use of 3rd party developers.

The 2nd case the defined a propriety, the only true advantage of doing is that that data binding does not work with fields. There is however a big political advantage in using proprieties, you get a lot less invalid complaints from other developers that look at your code.

All the other advantages for proprieties (that are well explained in the other answers to your questions) are not of interest to you at present, as any programmer using your code can change the field to a propriety later if need be and just recompile your solution.

However you are not likely to get stacked for using proprieties, so you make as well always use public proprieties rather the fields.