Once again, in this series of posts I look at the parts of the .NET Framework that may seem trivial, but can help improve your code by making it easier to write and maintain. The index of all my past little wonders posts can be found here.
Visual Studio 2015 is on the horizon! In fact, some of you may already have played with the preview and seen some of the many neat new things to come – both in the IDE and in the C# language.
Note: All of the C# 6 features mentioned are current with the latest CTP of VS2015 as of the time of this writing. The syntax and exact feature behaviors may be subject to change in the final released version.
Reducing syntax for trivial tasks
As we’ve seen in my previous posts on C#, a lot of the focus has been on simplifying syntax to remove some of the burden of common code and syntax for mundane activities.
One of the areas where we see a lot of syntax for something that should be fairly simple is in writing those somewhat trivial members that simply return trivial values or expressions.
For example, let’s say you have the following class defined to represent a Rectangle:
1: public class Rectangle
2: {
3: public int Length { get; set; }
4: public int Width { get; set; }
5:
6: // that's a lot of syntax for just getting L * W
7: public int Area
8: {
9: get
10: {
11: return Length * Width;
12: }
13: }
14:
15: // here too...
16: public int Perimeter
17: {
18: get
19: {
20: return 2 * (Length + Width);
21: }
22: }
23:
24: public override string ToString()
25: {
26: return $"Rectange: Length={Length}, Width={Width}";
27: }
28: }
Notice how sleek and elegant the auto-properties look? But how much syntax we need for a simple get-only property that just returns a trivial expression? Sure, we can inline the whitespace to somewhat reduce our “vertical bloat” headache, but it’s still a lot of syntax.
This is why the folks at Microsoft working on C# 6 decided they could help with this and reduce the syntax of members where you want to simply return an expression and eliminate some of the unnecessary syntax.
Expression-Bodied Get-Only Properties
Now, if you have a property that is get-only, you can write the body of the property using the expression syntax. That is, you can use the lambda-expression syntax to write the body of the property.
That is, instead of writing the { get { return your expression; } } syntax, we can simply write => your expression;
For example, if we convert our get-only properties above, we can get:
1: public class Rectangle
2: {
3: public int Length { get; set; }
4: public int Width { get; set; }
5:
6: // much more concise!
7: public int Area => Length * Width;
8: public int Perimeter => 2 * (Length + Width);
9:
10: public override string ToString()
11: {
12: return $"Rectange: Length={Length}, Width={Width}";
13: }
14: }
This removes a lot of the standard get property syntax for trivial properties that just result in a simple expression. Now, you may ask, does this have any performance implications at runtime? Actually, the answer is no. This is simply syntactical sugar that expands into the same IL as writing the full body. It does not create a delegate, it is simply borrowing the lambda expression syntax to simplify writing simple bodies that result in an expression.
Unfortunately, at this time, there is not a simplified syntax for setters, nor can you use this syntax for the getter and specify a setter long-hand, it only works on get-only properties (and methods as we’ll see below).
Expression-Bodied Methods
So, what about our friend the ToString() method up above. It too returns a simple expression, could we use the syntax for methods as well as for get-only properties?
Yes, we can:
1: public class Rectangle
2: {
3: public int Length { get; set; }
4: public int Width { get; set; }
5:
6: public int Area => Length * Width;
7: public int Perimeter => 2 * (Length + Width);
8:
9: // eliminated a wee bit o'syntax here
10: public override string ToString() => $"Rectange: Length={Length}, Width={Width}";
11: }
Granted, I think we’re reducing less syntax here than we did with the get-only property, but it can still be nice for very simple methods. The new syntax is even available for void methods, for example:
1: public class MyCache<T>
2: {
3: private ConcurrentDictionary<string, T> data = new ConcurrentDictionary<string, T>();
4:
5: // simple method which simply clears the dictionary
6: public void Clear() => data.Clear();
7: }
Again, there is no magic or delegates behind the scenes, it is simply borrowing the lambda expression syntax to allow you to specify a method body in a simpler form.
So, should you use this? It all comes down to style. My gut would be to limit this to simple expressions and statements that can clearly be understood at first glance.
Summary
So C# 6 now gives us the ability to specify get-only property and method bodies with expressions. This can help reduce the syntax burden of very simple methods to make your code more concise.
However, with all things, use your judgment on whether it fits for any given situation. When an expression is very long or complex, using the full body syntax may still be more readable.
Thanks for reading and stay tuned for more features of C# 6!
Print | posted on Thursday, May 14, 2015 7:08 PM |