As a software engineering instructor, one of the language features I appreciate the least about C# are the expression-bodied members introduced in C# 6 and 7. In this short article we'll cover what expression-bodied members are, what they do, and when you would use them. We'll also talk about why I'm cautious about their prevalence in a C# codebase.
Traditional C# Classes
To start, let's look at a simple class without expression-bodied members:
public class GameObject
{
public string Name { get; set; }
public int MaxHitPoints {get; set;}
public int CurrentHitPoints {get; set;}
public bool IsDead
{
get
{
return CurrentHitPoints <= 0;
}
}
public bool IsFullHitPoints
{
get
{
return CurrentHitPoints == MaxHitPoints;
}
}
public int TakeDamage(int damage)
{
CurrentHitPoints -= damage;
return CurrentHitPoints;
}
}
This is intentionally a very simple class. In a more real-world class I'd likely add in some argument validation and make sure that CurrentHitPoints never went below 0 or above the MaxHitPoints, but this will suffice for our demo code.
There's nothing really wrong about this code, but the code also isn't doing very much and it does take up a decent amount of screen space for the amount of code it is.
C# Expression-bodied Members
Because of this, some programmers prefer to use C# expression-bodied members to simplify single-line methods and property accessors.
With expression-bodied members, we can replace the get / set syntax for simple properties with fat arrows which are denoted as => in code.
Note: to keep my students focused during lecture, I sometimes refer to these as "chonk arrows", but "fat arrows" is far more standard of a term.
Using the fat arrow syntax of expression-bodied members, our code becomes the following:
public class GameObject
{
public string Name { get; set; }
public int MaxHitPoints {get; set;}
public int CurrentHitPoints {get; set;}
public bool IsDead => CurrentHitPoints <= 0;
public bool IsFullHitPoints => CurrentHitPoints == MaxHitPoints;
public int TakeDamage(int damage) => CurrentHitPoints -= damage;
}
This is considerably smaller in terms of the number of lines of code while maintaining the same behavior.
Does this mean the expression-bodied member syntax is better?
I suppose it depends.
Should I use Expression-Bodied Members in my C# Code?
Everything in software is about tradeoffs. Using expression-bodied members we gain a few advantages:
- Our code is more compact, increasing the amount of application logic that is visible on the screen at any time
- We spend more time writing relevant code and less time writing generic C# syntax
- We get to say "fat arrow" and "chonk arrow" during code reviews
Of course, C# expression-bodied members also carry some drawbacks:
- They terrify new learners joining your team who might not have seen them before
- Even for experienced developers the single-line
=>can slow down the readability of code - If you find you need to expand to multiple lines of code during maintenance, you have to backtrack and use the traditional member body approach detailed earlier
In my own C# code I tend to use expression-bodied members, particularly when it is only me on a project.
I also tend to format my expression-bodied members in unusual ways when I believe it will improve code readability:
public class GameObject
{
public string Name { get; set; }
public int MaxHitPoints {get; set;}
public int CurrentHitPoints {get; set;}
public bool IsDead =>
CurrentHitPoints <= 0;
public bool IsFullHitPoints =>
CurrentHitPoints == MaxHitPoints;
public int TakeDamage(int damage) =>
CurrentHitPoints -= damage;
}
Here I trade some of the compactness of expression-bodied members by moving their implementation down to the next line.
Remember: code is far more relevant during long-term maintenance than it is when originally writing it. Because of this, we need to craft our code with long-term maintenance in mind.
Expression-bodied members and their impact on New C# Devs
As I teach, I try to put off the first time a student sees expression-bodied members. I usually wait until after they've encountered LINQ or seen JavaScript arrow functions. Once that happens, I show them expression-bodied members as an alternative to what they already know.
Why do I wait? Expression-bodied members are more intimidating to read. Additionally, new learners have to ask themselves "should I use this instead of a normal method body?" and that decision can distract them from their core task.
Even if a new learner is familiar with expression-bodied members, their presence in a project usually adds significantly to the learner's anxiety and the perceived complexity of the code.
I'm not saying you shouldn't use expression-bodied members. However, I would make sure you understand that the more you use them the harder new developers will find it to explore your codebase during onboarding.
If you do not expect to have many new developers, your code is not very complex otherwise, or you're willing to spend more time during onboarding, expression-bodied members can make your code a lot more focused.
