C# 6.0 – nameof Expressions

[7/30/2015] This article was written against a pre-release version of C# 6.0. Be sure to check out the list of my five favorite C# 6.0 features for content written against the release!

I’ve lost track of the number of times I’ve needed to pass along the name of something be it a property, method, or type. Historically we’ve relied on hard-coded strings to convey this information but as we’re all too well aware, relying on strings in such a manner is just asking for future problems. For a prime example, we need look no further than our old friend INotifyPropertyChanged.

Consider the following Circle class which typifies the basic INotifyPropertyChanged implementation pattern:

public class Circle
  : INotifyPropertyChanged
{
  public event PropertyChangedEventHandler PropertyChanged;

  private double _radius;
  public double Radius
  {
    get { return _radius; }
    set
    {
      _radius = value;
      RaisePropertyChanged("Radius");
    }
  }

  private void RaisePropertyChanged(string propertyName)
  {
    if (PropertyChanged == null) return;

    PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
  }
}

Although this class is pretty boilerplate, it highlights the problem well. First, we’ve violated the DRY principle by encoding a member name in a string. Next, we’ve introduced fragility by relying on the string always reflecting the property name exactly; should the property name ever change we need to remember to change the string as well lest we waste some cycles tracking down why an event handler isn’t picking up the property change. What’s worse is that by encoding the name within a string, we get no compile-time support alerting us to the discrepancy.

The story around INotifyPropertyChanged and other similar scenarios has improved over the years as people have come up with some creative solutions. For instance, I’m particularly fond of the expression tree approach because despite its added complexity, it adds the compile-time support lacking in the string-based approach and ties in nicely to Visual Studio’s built-in refactoring capabilities.

.NET 4.5 improved the story a bit more by introducing a few attributes we could apply to optional parameters to get information about the method caller with CallerMemberNameAttribute being the most notable for this discussion. By decorating a parameter with CallerMemberNameAttribute as shown in the revised RaisePropertyChanged method that follows we’re instructing the compiler to inject the name of the member that invoked the method.

private void RaisePropertyChanged([CallerMemberName] string propertyName = "")
{
  if (PropertyChanged == null) return;

  PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}

With this revised version, we could simply invoke the method without passing the name and the compiler would resolve the name for us. The problem with this approach is that there’s nothing in IntelliSense to inform us that the parameter is decorated with the attribute and there’s nothing stopping us from providing a value. In fact, the compiler won’t even warn that a name won’t be resolved if we do provide a value. Furthermore, while CallerMemberNameAttribute works nicely for this example, it’s only useful when we need the caller name so it won’t help us if we need the name of anything else such as a parameter name. That’s where the new nameof operator comes in.

C# 6.0’s nameof operator is used to resolve the name of an item at compile-time, essentially inserting the string into the compiled code. What’s really great about it is that it’s simple to use and works on any symbol.

In keeping with the INotifyPropertyChanged example, in C# 6.0 we can add compile-time safety to the original example code simply by replacing:

RaisePropertyChanged("Radius");

with:

RaisePropertyChanged(nameof(Radius));

There are plenty of other places I can see the nameof operator coming in handy. For instance, I often like to use a Guard class to perform a variety of pre-condition checks against method parameter values. Such a class typically looks a bit like this:

public sealed class Guard
{
  private static Lazy<Guard> _against = new Lazy<Guard>();

  public static Guard Against { get { return _against.Value; } }

  public void Null(string arg, object value)
  {
    if (value == null) throw new ArgumentNullException(arg);
  }

  // additional guard methods here
}

I generally create the Guard class as a sealed singleton class rather than as a static class to not only create a more English-like API, but also to allow extension methods in certain scenarios. I also like defining the Guard class methods as a fluent interface but omitted that for brevity.

Given that the Guard class operates off of arguments rather than callers, adding parameters decorated with CallerMemberNameAttribute clearly won’t work in this scenario. Instead we can simply update calls to the various methods to use the nameof operator instead of a hard-coded string and our code will immediately be less fragile.

Advertisement