What is the point of auto generate instvar?

Question

Since C# 3.0 there is the new syntax to autogenerate the instance variable from a propertie:

public string Foo { get; set; } 

But there is no way to access the underlying backing field. So I don't really see the point of it because declaring the same instance variable would produce the same effect without the overhead of calling the "getter" and "setter".

public string Foo;

Declaring the property like:

public string Foo { get; } 

or

public string Foo { set; } 

is totally useless since we are not able to write resp. read the content of the field.

Does someone have a good explanation for why in C# they have put all this effort to introduce this syntactic sugar?

EDIT: People seems to think that I am confusing field and properties so let me clarify what I have said.

If you are using a property with auto generate field:

public string Foo { get; set; } 

Then there is no point to it, since whenever you access the properties there is the overhead call to the get_Foo() "getter" every time you are accessing the properties and since your aren't doing anything particular in the the "getter" there is not mush interest of creating this property. Creating the field would have been exactly the same and it is mush faster (optimization wise).

Thanks

Answer 1

public string Foo { get; set; } public string Foo { get; set; } defines a property.
public string Foo; defines a field.

They are different things. And the former is very convenient when you actually want a property and not a field.

As for accessing, you can define different access levels:

public string Foo { get; private set; }

See also Difference between Property and Field in C# 3.0+

---

As for your edit, what you are saying only makes sense if:

1. You are 100% sure that your property accessors will never contain any actual logic.
2. You are 100% sure that your field will never be data bound.

If any of the above is not true, then you need to define a property, even if that property seems like an empty stub.
Then, when later you decide to add logic to the accessors, you will not break all those clients that rely on your field being a field.
And if your class may be data bound, you need a property right away, as the data binding mechanisms ignore fields.

Answer 2

public string Foo; 

Is a field.

public string Foo { get; set; }

Is a propery. They aren't the same thing, which has been discussed before. One of the mainly propagated advantages is the access control: get; private set; get; private set; is used quite often as an example.

But there is no way to access the underlying backing field.

Yes there is, by calling the getter. Use [this.]Propertyname when you want to access it locally.

---

public string Foo { get; } 

and

public string Foo { set; } 

Will give you compiler errors, since you have to implement both get and set .

Answer 3

The point of it is to make the code more concise and give you less to type.

In your example:

public string Foo;

Is a field and isn't the same as a property:

public string Foo { get; set; }

So the auto-property syntax has a use and is somewhat equivalent to:

private string _foo;
public string Foo { get { return _foo; } set { _foo = value; } }

However it doesn't create nice names, it uses safe names that would be invalid in C# (but are valid in IL).

Property overhead, though technically possible, is usually ironed out by the JIT into direct field access.

Properties are also usually the target for most data-binding frameworks. In reflection, a property differs from a field. WPF / WinForms data binding uses properties (not public fields). Most properties use a backing field to store the data. The trade-off is that when in the class, you use the property still as opposed to using the backing field. In practice, on release-optimized code, the performance is exactly the same as the JIT resolves them into exactly the same thing.

Answer 4

By itself it's pointless, but you can do things like this:

public string Foo { private set; get; } 

Which has a lot more value.

Also properties and fields are not the same things.

Answer 5

It makes defining properties faster and the code cleaner. If you don't need a property then don't define one - but I would recommend against public fields. You can make the property private and accessing it doesn't do anything more than returning the IL defined field. Further, if you need to do some work in the get or set then you'll have to define a backing value somehow, whether that be a field or some inherited member.