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

February 26, 2008


TrackBack URL for this entry:

Listed below are links to weblogs that reference Timesaver: Awesome New C# Property Syntax Shortcut:



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)


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.