I know that this post is going to be old hat for the vast majority of you, and if this is the case, then please just ignore this post. More than likely though, you’ve come across someone that needs to read this post, and if so please pass it on!
If you’ve been using C# 3.0 for long enough then you have probably started using a neat little piece of syntactic sugar called automatic properties.
For the uninitiated, instead of writing this:
public class Person
{
private string firstName;
public string FirstName
{
get { return firstName; }
set { firstName = value; }
}
private string lastName;
public string LastName
{
get { return lastName; }
set { lastName = value; }
}
}
You get to write this:
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
And yes, we aren’t performing magic, it is just shorthand for the properties above, and you can clearly see that if you reflect it. I won’t show you the IL here, but you can just trust me. 🙂
Unfortunately, for most developers, the above use of automatic properties is where the fun stops. Once they get to the point where they need to have a read-only property, they fall back to their old tricks and write this:
public class Person
{
private string firstName;
public string FirstName
{
get { return firstName; }
}
private string lastName;
public string LastName
{
get { return lastName; }
}
}
Boooooooo! You don’t need to do that silly developer. You just need to do this:
public class Person
{
public string FirstName { get; private set; }
public string LastName { get; private set; }
}
See, now how hard was that? Now you have a public property with a private setter. You can also use protected or internal, so that you can set it from inherited classes and within the same assembly:
public class Person
{
public string FirstName { get; protected set; }
public string LastName { get; internal set; }
}
And yep, you can even create a write-only property, although this has less usefulness:
public class Person
{
public string FirstName { private get; set; }
public string LastName { private get; set; }
}
So you have all of the functionality you need, unless you require some custom logic be inside of your getters or setters. If you haven’t been aware of these features of automatic properties then first get out from under your rock, and second, go out there and delete some code! Hope you enjoyed!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
Wow, didn’t know about that.
I considered auto properties incomplete feature. They missed functionality that readonly keyword provides for fields. And in case of struct I need call empty ctor first, that switches off validation of field initialization completeness.
So all my read only properties are backed with readonly fields.
I think it will be better to eliminate fields from language at all. Let all be property and let fields be implementation details. I mean that field declaration should create auto property and there should be no way to create pure field from C#. This should not have performance impact because I’m sure all simple properties are inlined by JIT/ngen. This can only change something in native interop but no more than adding one additional attribute.
Eliminating properties, I think, will simplify the language a bit. It will be unnecessary to explain why fields should not be public or protected over and over again.
*Eliminating fields (in last sentence)
Or use the Visual Studio shortcut "propg". This inserts the template for an automatic property with a public getter and a private setter.
Now we just need Auto Implemented Properties "null default value" settings. For instance, for a string property that is null, default to String.Empty. Something like:
public string FirstName { get default String.Empty; set; }
To do this otherwise you have to revert to a backing store.