C# 3.0 auto-properties — useful or not? [closed]

Question

We use them all the time in Stack Overflow.

You may also be interested in a discussion of Properties vs. Public Variables. IMHO that's really what this is a reaction to, and for that purpose, it's great.

Yes, it does just save code. It's miles easier to read when you have loads of them. They're quicker to write and easier to maintain. Saving code is always a good goal.

You can set different scopes:

public string PropertyName { get; private set; }

So that the property can only be changed inside the class. This isn't really immutable as you can still access the private setter through reflection.

As of C#6 you can also create true readonly properties - i.e. immutable properties that cannot be changed outside of the constructor:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

At compile time that will become:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

In immutable classes with a lot of members this saves a lot of excess code.

The three big downsides to using fields instead of properties are:

1. You can't databind to a field whereas you can to a property
2. If you start off using a field, you can't later (easily) change them to a property
3. There are some attributes that you can add to a property that you can't add to a field

I personally love auto-properties. What's wrong with saving the lines of code? If you want to do stuff in getters or setters, there's no problem to convert them to normal properties later on.

As you said you could use fields, and if you wanted to add logic to them later you'd convert them to properties. But this might present problems with any use of reflection (and possibly elsewhere?).

Also the properties allow you to set different access levels for the getter and setter which you can't do with a field.

I guess it's the same as the var keyword. A matter of personal preference.

From Bjarne Stroustrup, creator of C++:

I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure.

And you know what? He's right. How often are you simply wrapping private fields in a get and set, without actually doing anything within the get/set, simply because it's the "object oriented" thing to do. This is Microsoft's solution to the problem; they're basically public fields that you can bind to.