I am strongly in favor of automatic properties. They make code more readable and more concise. And that's often no easy task. However, I have seen a lot of people get tripped up by automatic properties because of the restriction that you must implement both the setter and getter. It's often good practice though to limit what consumers of your object can do. For example, only allowing them to read the property value is one way to enforce immutability. But what ends up happening in this case is that the most people start out trying to do something like the following:
1: public string FirstName
2: {
3: get;
4: }
This obviously does not compile because of the aforementioned restriction: you must implement both the getter and setter. Defeated and depressed by the compiler, most developers quickly resort to old habits and create a private backing field and move on with their lives. They end up with something like this:
1: private string firstName;
2: public string FirstName
3: {
4: get { return this.firstName; }
5: }
They've introduced additional overhead for a simple property that was entirely unnecessary. This additional backing field can now also be mistakenly used in the current code; making refactoring and maintainability that much harder than it needed to be. You can create 'get-only' or 'set-only' properties by using the access modifiers. In this case, we can create a get-only automatic property by marking the setter as private.
3: get; private set;
And since simple properties are very common, this new construct should be used liberally.
Adieu. Navid.
UPDATE: I have made some changes to the verbiage to make it the post clearer as per the comments. Thanks!