Who doesn’t love to delve into new language syntax when it’s provided; Upcoming C# 6 sports lots of new syntax improvement. If you currently use Visual Studio, you’ll love the fact that you won’t need to change your existing application’s target .NET framework to use C# 6. In fact, it’s a relief. If you’re targeting .NET 4.0 or even .NET 3.5, you can use C# 6 in Visual Studio 2015 with ease. I took some time off from my current projects to play with the new features of C# 6 with Visual Studio 2015 Preview and what I found most impressive were these two language features:
The c# nameof expression
If you are a WPF developer or ASP.NET MVC developer, you already know the pain of using a Property name in your code. Either you had to use magic string, or you had to use a Reflection based wrapper code to read the name of the property. When you wrote your WPF ViewModel class, you might have needed to write code like this:
Most of the developers usually create a wrapper over the Reflection based code so that they can pass the strongly typed property name to that wrapper method. But both of these approaches have problems. First of all, using a magic string is a awful practice. In the future, anytime you change the property name, your magic string dependent code will break. Magic String has a high maintenance cost attached to it. But also think about this when you are using a Reflection based wrapper to pass a strongly typed Property name, how much will it cost in performance.
C# 6 gives you a new way to get the property, or any member name, using a 'nameof' expression. It looks like a 'typeof' operator. You can use the nameof expression in your WPF ViewModel's PropertyChanged invoker as follows:
And guess what! This nameof expression is evaluated in compile time, same like a const member. When you compile your code, the compiler will replace the "nameof(Message2)" part with "Message2". So, you save from high code maintenance cost by not using the magic string, at the same time, your application will be faster because it does not read the property name using Reflection. I wonder, why this feature was not available from the very first version of C#. It was a badly needed feature from the start. I would say it is not just a syntax improvement, feature; rather, it is a feature that will inspire you to re-architect your application. I am already thinking about redesigning my WPF ViewModels to utilize this feature.
If you are a developer of ASP.NET MVC, then, you must have needed to write Editor Templates at some point. In editor templates, a lot of the time, you'll need to get the Model's Property name so that the property name can be written as an HTML input field variable, right? Here is my Editor template for a class called 'Money'.
So, you notice that "Amount" is a property of the class 'Money' which is used as a string in the 'TextBox' method. So, using the nameof expression will save us from using magic string.
If you have worked with LINQ to XML, then you must have been frustrated and annoyed when you had to check for null every time you read an element. Let's show a typical LINQ to XML code.
Now, how excited will you be if you see that this code block can be rewritten using C# 6 as follows?
Yes, right. C# 6 gives you a new operator '?.' which will allow you to get a member of an object only if the object is not null. If the accessing object is null, then this operator will return the default value (null for reference type object) for the returning type.
Think about it, how many times have you faced a Null Reference Exception for a code snippet like this!!?
Once you faced the null reference exception, you had to write an if statement checking if the userName is null or not, as follows:
Is not it cool that using C# 6, you can simply rewrite your statement like this?
To excite you more, I would like to demonstrate the following code snippet where you can find that - this null conditional operator can be chained.
Are you wondering what the return type of '?.' operator is ? The return type is the 'nullable' of returning member type. If we look into the above example, the member 'Size' is an int type. Therefore, it is returning Nullable Int which is same as 'int?'.
The last exciting point I would love to demonstrate about this null conditional operator is triggering an event only if it's non-null. Remember the WPF ViewModel property we discussed earlier in this blog, we refactored the PropertyChanged event invoker statement as:
With the new null propagation feature of C# 6, you can rewrite the snippet as follows:
Is not it simply awesome?
Check out more about C# 6 from the Channel 9.
Please feel free to share your comment.