Timesaver: Awesome New C# Property Syntax Shortcut

I just could not believe this! No, this cannot be, how did Microsoft know that I wanted this feature!

Well ... today I discovered this new shortcut writing properties in C# 3.0 using Visual Studio (actually I was using the C# Express edition). Lets say we want to have a class called person who has age and name. In C# 3.0 there is no explicit need to declare a variable and write get and set methods for the property.

I could just declare the class like this ...

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

And then use it in code like this

 Person p = new Person();
 p.Name = "Me";
 p.Age = 31;

This saves so much time. I just love this ...awesome way to define properties. Well I could also use the named parameters style code like this ...

Person p = new Person() { Name = "Me", Age = 31 };

C# has just gone crazy ...

How does this work?

Well if I try to decompile the code using Reflector then we would see that we have this following code for the class Person

internal class Person
{
    // Fields
    [CompilerGenerated]
    private int <Age>k__BackingField;
    [CompilerGenerated]
    private string <Name>k__BackingField;

    // Methods
    public Person();

    // Properties
    public int Age { [CompilerGenerated] get; [CompilerGenerated] set; }
    public string Name { [CompilerGenerated] get; [CompilerGenerated] set; }
}

Looks the like the following code was generated by the compiler ... I am still not clear how the "<PropertyName>k__BackingField" expression is used in sync with the compiler generated attribute, but I am happy that I have such a shortcut.

Comments

[Jemm]

Those Automatic Properties are even faster to type, when you use Code Snippets:
Type "prop", press TAB twice and then just type in the datatype and identifier to the placeholders.

I like also that the classes (typically DTOs) stay clean when using the Automatic Properties.

It is also very easy to copy the properties to interface specifications (or vice versa): just delete or add the access modifiers.

[EtienneT]

This is nice, but my question is how is it different then a public variable in the class? There's most probably some advantages to use this over a public variable, but I can't find any... Could you illuminate me on this please? Thanks.

[Chad Myers]

@Etienne That's a great question. The point with properties is that, at a later date, if you needed to change how the getter or setter worked, you could without forcing all the callers to recompile their apps.

If you were just using a public field, and you later switched it to a property, the interface (signature) of the class changes and now all the callers will have to recompile or get things like "MissingMethodException", etc.

[Steve Bohlen]

Also don't forget that you can combine this with inline property-initialization too so that instead of...

Person p = New Person();
p.Firstname = "john";
p.Lastname = "Doe";

...you can instead use...

Person p = new Person() { Firstname="John", Lastname="Doe" };

...and get it all into a single line when you construct your classes too.

Just more syntactic sugar that the C#3.0 compiler translates into the long-hand version but with a slight advantage:

In the long-hand version, if setting one of the properties throws an exception, you get an object that exists but is in an incomplete state of initialization but in the short-hand inline version if any part of the statement fails, then the object is left as == null (which of course is something that you can test for).

As I say, more goodies from the C#3.0 compiler :)

-Steve B.

[Shafqat Ahmed]

Chad, thanks a lot for answering Etienne's question. I agree with you.

[Jemm]

One reason to use (automatic) properties instead of public fields is that the properties can be inherited. Properties also can be required in interfaces while fields can't be.

[Niki]

@Etienne: Properties have a few advantages over public fields:
- You can declare them virtual, so derived classes can override the behaviour
- You can specify a different visibility for the setter (e.g. public int Test { get; private set; }), making the property visible, but not changeable from outside (For me, this is the #1 reason to use them)
- In the Debugger, you can set a breakpoint on a setter
- If you're implementing an interface, you can now implement a interface property with one line (you can't implement it with a public field)

[Shafqat Ahmed]

C# 3.0 object initialization has a little difference ... read this

http://community.bartdesmet.net/blogs/bart/archive/2007/11/22/c-3-0-object-initializers-revisited.aspx

[Jimbo]

Neat tip but hardly awesome. I don't like the way you lose control of the internal naming though. Will stick to the longhand.

[Mystified]

This is dumb. There is no practical difference between this:

class Person
{
public string Name { get; set; }
public int Age { get; set; }
}

and this:

class Person
{
public string Name;
public int Age;
}

[Shafqat Ahmed]

For me it was awesome, cause I dont like fields rather like properties and this gives me the way to write properties in a shorter format and I can just customize get and set if I want a specific property to be customized. Also Interface definition and implementation just got easier DTO style objects and interfaces.

[Traci]

Very useful post, and the "prop-Tab-Tab" shortcut posted by Jemm could be a great timesaver. I'm not usually one to promote books, but for those who are interested, "Accelerated C# 2008" seems to have a decent coverage of features new to 3.0, such as the automatic properties described here. Pretty dense reading, however, for novices such as myself.

[Nathan Le]

I agree. The "prop- Tab- Tab" shortcut posted by Jemm works wonder for me. Thank you.

[King Wilder]

To Mystified, regarding your comment about "this is dumb"... it actually isn't.

The practical difference is that you can apply business rules to properties, but not to class members.

Example: how would you prevent someone entering 10000 as their age with a public member? You can't!

[Lior]

why not just use the Reflactor-> Encapsulate field?