Proper C# Property Standards

Historically, the second approach was created first, and only later the semantically equivalent syntax of auto-implemented properties emerged. The benefit of this new syntax in development looks quite apparent, let's not discuss it.

Let's discuss only the potential name conflict you just mentioned. Apparently, the conflicts are possible. But what are the implications of them? The simple fact is: you don't add many potential conflicts compared to the simple fact that one or two hidden names are already created: the names for setter and getter, but these names are standardized. I tested the code showing the backed field names:

class Program {
    int autoImplementedProperty { get; set; }
    static void Main(string[] args) {
        Type tp = typeof(Program);
        FieldInfo[] fi = tp.GetFields(BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.Instance | BindingFlags.Public);
        System.Console.WriteLine(fi[0]);
    }
}

Look at the result: the backing name appeared to be: "<autoImplementedProperty>k__BackingField". It is simply syntactically impossible to code any name conflicting with this one!

And now, if you are simply using properties, even not auto-implemented, you actually can have a conflict which is worse. Add this method:

int get_autoImplementedProperty() { return 0; }

or this:

void set_autoImplementedProperty(int value) { }

In either case, you get an error message: "Type 'Program' already defines a member called '<method_name>' with the same parameter types".

So, where is the problem? Actually, Microsoft created original conflicting situation, and the solution was the standardization of the backing method names. You simply should know these names and avoid them. Is it good? Not quite. Is it a real problem? No, because — try to do it and see how easy the fix would be: you simply read the compilation error message and rename the method appropriately.

By some reason, the authors of those "couple of C# books" don't see a problem here, even though the situation is not quite perfect. They see a problem where it is impossible to create a conflict, simply because they don't understand the essence of things: the auto-generated backing field names are simply syntactically impossible. They told you something which is directly opposite the real situation. The problem can only appear in some hypothetical future language where the name of members could be some XML text. But this is a problem of the authors of such languages and compilers. Hope, they are going to be less stupid than the authors of those "couple of C# books".

The real problem is that there is no any guarantee that the backing field keep there names during compilation. Theoretically speaking, it's possible to get those name via Reflection and use it somewhere, importantly, in Persistence. Is it a problem or not? I think this is not a problem: this is a stupidity which is too sophisticated to be taken seriously. Not that this is impossible: of course, programming should be based on assumption that any stupid use can take place. How about this kind of stupidity? I'm sure that it's not a problem, in the following sense: simply put, such a sophisticated design mistake can be done only by a person who has the talent to screw up things much worse. We all understand that programming systems should not protect from sophisticated stupid tricks but should only promote stable well-supportable style of programming.

And finally, I must say a work of those "couple of C# books". Many, many books on practical software development (concrete systems and languages), development method, organization of development are a permanent source of frustration for me, in such rare moments when I go to the bookstore and scan them. I almost never see decent books on the topics I can judge about. You need to be careful and use your own brain.

—SA

When it is such a simple situation like the one you described (just get and set without any extras), I prefer the short style.
But sometimes, some extras are required, mainly with the setter: e.g. checking for a valid value (not null, bigger than x, smaller than y, ...), or firing a PropertyChanged event, or Logging, ... And then you need the more verbous style.