Any reason to use auto-implemented properties over

Question

I understand the advantages of PROPERTIES over FIELDS, but I feel as though using AUTO-implemented properties over MANUAL implemented properties doesn't really provide any advantage other than making the code a little more concise to look at it.

I feel much more comfortable using:

    private string _postalCode;

    public string PostalCode
    {
        get { return _postalCode; }
        set { _postalCode = value; }
    }

Instead of:

public string PostalCode { get; set; }

primarily because if I ever want to do any kind of custom implementation of get and set, I have to create my own property anyway backed by a private field. So why not just bite the bullet from the start and give all properties this flexibility straight away, for consistency? This really doesn't take but an extra second, considering that all you have to do in Visual Studio is click your private field name, and hit Ctrl+E, and you're done. And if I do it manually, then I end up with inconsistency in which there are SOME manually created public properties backed by private fields, and SOME auto-implemented properties. I feel much better with it being consistent all around, either all auto or all manual.

Is this just me? Am I missing something? Am I mistaken about something? Am I placing too much emphasis on consistency? I can always find legitimate discussions about C# features, and there are almost always pros and cons to everything, but in this case, I really couldn't find anyone who recommended against using auto-implemented properties.

Answer 1

It doesn't grant you anything extra beyond being concise. If you prefer the more verbose syntax, then by all means, use that.

One advantage to using auto props is that it can potentially save you from making a silly coding mistake such as accidentally assigning the wrong private variable to a property. Trust me, I've done it before!

Your point about auto props not being very flexible is a good one. The only flexibility you have is by either using private get or private set to limit scope. If your getters or setters have any complexity to them then the auto props are no longer a viable option.

Answer 2

There are people who think that automatic properties can be somewhat evil but apart from that they are just syntactic sugar. You don't gain anything by using them apart from saving a few lines of code and you can potentially create more work for yourself (by having to implement it manually anyway later on because you want to do some checking or raise an event). Consistency is quite valuable in programing (imho).

Answer 3

One of the things that you will lose control over is the ability to specify the backing field as NonSerialized, but it is easy enough to create a backing field for the property in this case.

Forgot: if you or any product that you use performs reflection on the members (i.e. WCF), then you will see the mangled backing field name instead of a "pretty" backing field that you created.

This could be very important if you had previously provided access to the service or if you deserialize on the receiving end into the same class structure (i.e. the same classes are used on both ends of the WCF pipe). In this case, you would not necessarily be able to deserialize because you could guarantee that the backing field name is the same unless you share the same DLL as opposed to the source code.

A little more clarification: assume that you have a web service that exposes some of your business objects over WCF to a silverlight client that you have created. In order to reuse your business logic, your Silverlight client adds references to the source code for your business objects. If you have auto-implemented properties, you have no control over the backing field name. Since WCF serializes the members and not the properties, you cannot be sure that the object transferred to silverlight from the WCF service will deserialize correctly because the backing field names will almost certainly be mismatched.

Answer 4

One of the advantage I see using auto properties is; while debugging the application it won't step into unnecessary Get/Set section. I know that we can avoid same using Debugger Attributes or Step over; however it happen most case if be do debug on a large application.

Answer 5

Auto-implemented properties are not guaranteed to keep the same backing field name between builds. Therefore, it is theoretically possible that serializing an object in one version of an assembly, and then re-serializing that same object in another assembly could cause breaking changes.

This is highly unlikely, but it is a valid concern if you're trying to maintain the ability to "swap out" version of your assemblies for newer versions.

By using manually implemented properties, you're guaranteed that the backing field never changes (unless you change it specifically).

Aside from that minute difference, an auto-property is a normal property that is implemented automatically with a backing field.

Answer 6

I don't know about everybody else, but I tend to pause a moment to think what I should name my variables and functions so others can understand my code.

So when I use auto-implemented properties, I only have to pause once.

When I need a backing field I have to pause two times, so it slows down development a bit :)

The way I do it is:

1. Make it a private variable in the start
2. Change it public auto-implemented if needed.
3. Change it to backing field if I need some code in get or set.

There is nothing wrong if different properties of a class are exposed differently.