.NET Basics : Explicit vs Implicit Interface Implementation
Strange C# 3.0 Feature: Partial Methods ... ... What ?!!

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
    private int <Age>k__BackingField;
    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.

kick it on DotNetKicks.com



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.


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.


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.


@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



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


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.


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!


why not just use the Reflactor-> Encapsulate field?

The comments to this entry are closed.