VS2010's "Public Property <PropertyName> As <DataType> vs. Public var

Question

In VS2008, I used to type

Public Property <PropName> As <dataType> 

and hit the Enter key and the IDE editor would automatically expand it out to a full blown property block.

Now, from what I understand, a new feature of 2010 is that the compiler automatically "expands" the short syntax above into the same IL code that you would get with the full property GET AND SET sub methods that were are accustomed to seeing before in the editor.

But functionality, how the heck is this any different than just having a Public class level variable? If the only diff is what it compiles to and if otehrwise there is no functional difference, isn't the new way less efficient than the old since it involves more code than just having a class level memory variable?

Public <Variable> as <DataType>

I thought that if you weren't going to have code behind your properties that they were essentially the same. I guess the diffrenece is that they just added the keyword "Property" but functionality, their is no diff, eh?

Answer 1

I am not sure, if I understand your question correctly.
But the need of a public class level variable vs property is already discussed here.

EDIT: Also, the IDE/Compiler makes it easy for you to reduce the code, if you are simply doing get/set

e.g. public string Name { get; set; }, which doesn't require you to declare a backing field.
But then,you will have to access this member (even inside the class) using the property. Because, the compiler generates a backing field for you & the name of it is unknown.

Answer 2

It makes little difference in this particular case, but I never use Public data members - anything that needs exposing outside the class is always done with properties. This means a little more work when declaring them, but when later on you wish that you had a property / accessor methods because you need to implement some code, it's a lot easier knowing that everywhere else in the code is already using your property...

Before someone pulls me up on this, no - it's not the same anyhow... You could manipulate a public member using a reference for instance...

Answer 3

This heavily ties into why properties are useful. They provide a level of isolation between the class implementation and the client code that uses it. When you use a public field, you cannot easily refactor the way the field behaves, the client code references it directly. Changing the field to a property for example requires recompiling all client code that uses it.

The usefulness of an automatic property is that it doesn't force you to decide up front that a field may need to be refactored some day. You can postpone the decision and change it from an automatic property to an explicit property with custom behavior any time you like. Without having to make any changes in the client code.

The JIT compiler ensures that an automatic property is just as efficient as a field, it inlines the accessor method call. The new automatic property syntax makes it just as efficient on your wrists as a public field. This is a complete win-win, it just doesn't make any sense anymore to ever use a public field again.

Answer 4

One other difference is that properties are accessed from other controls such as DataGridView, that can read public property values but not variables.

Answer 5

The major difference between Auto-Implemented Properties (VB) and public Fields are interface definitions.

Codes that are using your class with Auto-Implemented Properties does not need to change if in the future you decide to add logic to the property, whereas if you're using fields you will have to modify the interface definition to a property.

So Auto-Implemented Properties uses the simple syntax of a public Field (without the full blown property declaration) but with the flexibility of a property.

A little bit of example:

Current code (C#):

class PersonA {
  public int Age;
  public int BirthYear;
}

class PersonB {
  public int Age { get; set; }
  public int BirthYear { get; set; }
}

Usage:
var john = new PersonA { Age = 30, BirthYear = 1980 };
var jane = new PersonB { Age = 20, BirthYear = 1990 };

If in the future you decide to scrap Age setter and derive the value from BirthYear, you can easily update your class without breaking any of the current client code.

class PersonA {
  public int Age { get { return Date.Now.Year - BirthYear; }; set { } };
  public int BirthYear;
}

class PersonB {
  public int Age { get { return Date.Now.Year - BirthYear; }; set { } };
  public int BirthYear { get; set; }
}

Usage:
var john = new PersonA { Age = 30, BirthYear = 1980 }; // broken when not recompiled
var jane = new PersonB { Age = 20, BirthYear = 1990 };