Dangers of the ‘nameof’ Operator (c#)

TL;DR – The are hidden dangers in the ‘nameof’ operator in c# 6.

shotinfoot

 

Lately I have witnessed developers use new features that were presented in c# 6. My problem is not with using the new features, but with developers blindly refactoring their code just so that their code is “cutting edge” using and abusing the new language features without giving it much thought, as if their change is purely syntactic and does not change anything in the semantics of their program.

 

The are some very interesting and useful new features in c# 6, like string interpolation or the property auto initializers. But in this article I want to talk about the ‘nameof’ operator.

 

In short, the ‘nameof’ operator lets the developers be less dependent of pure string values. Here is a usefull example:

public string Name
 {
     set
     {
         // some setter code
         NotifyPropertyChanged("Name");
     }
 }

 

Imagine that now you want to refactor the property ‘Name’ to ‘FirstName’ because of some new requirements. You would need to always remember to change the string “Name” anywhere it was used, just like in the above example.
The new ‘nameof” feature allows you to write code as follows:

public string Name{
   set{
        NotifyPropertyChanged(nameof(Name));
    }
}

 

In this case when refactoring the ‘Name’ property, all uses in the ‘nameof’ operator will be refactored automatically with the help of your IDE.

 

So how can you shoot yourself in the foot with this operator, you ask? Pretty easily. And when you do – its pretty ugly, Lets see an example.
Consider the following code that extracts a value from configuration by providing a key:

Name = ConfigurationManager.AppSettings[nameof(Name)];

 

What would happen to this statement after the above mentioned refactoring? The result would be unpredictable. You might get an empty value, or maybe worse – you might get a value of some other key in the configuration file. This is pretty bad, I hope you see why.

 

This example is a simple one, but when you have a team working on the same code-base and some of the developers abuse the ‘nameof’ feature, you start dreading refactoring since you have no idea what you might end up braking.

 

To conclude, don’t blindly apply the shiny new features of your language just because they exist, use it when it’s appropriate. As a rule of thumb, I would suggest avoiding using the ‘nameof’ operator when used as a key in a key/value pair.

 

Enjoy coding,
Shonn Lyga.

About Shonn Lyga

Obsessed with anything and everything in Software Engineering, Technology and Science
This entry was posted in .NET, General Software, Software Design and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s