I can get why you might want to have a value that operates differently on receiving and returning a value, or even for just overloading, but I can't seem to see any use in just { get; set; }. I mean, isn't that exactly what a variable does, intake a value, store it, and then return it on call? Why would you use an indexer for that when you could just use a variable with one line of code?

It's good programming practice not to make variables public. Using this form allows you to keep the varible private but also allow it to be accessed publicly through the property. You should only add the property if you need to access it from another object.

There are some other useful aspects too, like being able to set a breakpoint whenever a value is changed (set it on the set line as opposed to having to set a breakpoint anywhere a variable is used).

If you are making a public API like the XNA framework and you wan to be able to ship binary compatible updates then you can't change a public field to a public property without breaking compatibility. This shortcut means you can make easy public properties that act like a public field. Then in the future if you need you can fill in the get/set without breaking things.

Generally its no use beyond that since as you correctly pointed out its the same as a public field.

You can pretend the data isn't public :)

I use the auto-implemented properties for a few reasons (some logical and some not so much):

1) It makes it really easy to later make it readonly by simply adding a 'private' onto the set part.
2) It's easy (with ReSharper) to quickly convert an auto-implemented property to a manually implemented property should I need to add more logic, meaning I type less now without having all that much work later if I need to add more to it.
3) I like seeing only the property icons in Intellisense. (Like I said, some not so logical :p)
4) I don't really see why not. It's slightly more typing than a public field, but given my OCD towards the icons and my first two points, I see no reason to use a public field in place of a property.

Here's one more...

5) Will fail code review if I don't use them :)

Properties are different from fields from the point of view of reflection, and classes like PropertyGrid that use reflection.

However, on the Xbox, properties are significantly slower than fields, because the compact CLR does not inline property access calls.

jwatte:

However, on the Xbox, properties are significantly slower than fields, because the compact CLR does not inline property access calls.

Sure they are slower, but it really all depends on the context. I used properties all over the place in Bloc (even for things like scores since they had to do work like setting a target value so I could animate the score changing) and never had any issue with it. It's another one of those "optimize if it is an issue, but don't assume it will always be" type of things.

I always feel internally conflicted by comments like "X is slower than Y on Xbox". On the one hand, it is really useful information to know and keep in mind. On the other hand, it tempts some programmers to do some premature optimization and change the statement "X is slower than Y" into the mantra "Never use X; always use Y."

If you have an auto property and it is a (profiled) performance problem due to heavy access plus the reason pointed out by jwatte, then you can change the auto property to a traditional property with an explicity declared private field, and have the class scope code access the field directly to reduce the property getter / setter performance hit. This of course will introduce bugs if logic is then added to the getter / setter so some caution is needed. The problem is we can't really profile for this can we, because we can only profile on the PC, which inlines the getter / setter calls of automatic properties.