Before discussing the `nameof` operator in C#6, I want us to consider why `nameof` exists at all. So, let's head back ten years to the heady days of 2005.
When version 2.0 of the .NET framework arrived, it transitioned the fledgling platform from a sketch of what might be to a fully-formed platform that could support ongoing and future desktop and web development. Since then, each release of the framework and its associated languages have added a variety of bells and whistles that simplify and enhance the way we develop. Among many of the concepts and types introduced by .NET 2.0 was `System.ComponentModel.INotifyPropertyChanged`, part of the enhanced data binding introduced to Windows Forms development. This interface turned out to be a workhorse and introduced many developers to a new problem; making sure the string that named a variable matched the name of an actual variable.
Now, you may well object to this claim since various versions of `ArgumentException` already demanded this of developers, but I think we both know that until our tooling got smarter (like FxCop and Resharper), many of us just did not fill that argument out if we could help it. After all, the stack trace would tell us where the crash happened, we could put something meaningful in the exception message, and keeping that variable name up-to-date after refactoring was a pain. With the advent of `INotifyPropertyChanged` the benefit of putting the variable name in a string started to outweigh the costs. Quickly, patterns emerged to try and simplify this, from dubiously performant uses of reflection to build-time code generation. As tools matured, we could get refactorings that took these strings into account and warnings that could shout at us if a variable was mentioned that didn't exist. Few of these were particularly elegant or entirely foolproof, and none were both1. In addition to `ArgumentException` and `INotifyPropertyChanged`, property names would be used for logging and debugging.
In the Name of Progress
There were calls for a new operator to accompany `typeof`; the new operator, `infoof`2 would provide the corresponding reflection information of a particular code construct (like `MethodInfo` or `PropertyInfo`), simplifying not just obtaining the name of something, but also any reflection operation involving that something. All this use and discussion of meta-information did not go unnoticed. Eric Lippert blogged about `infoof` and why it would be useful, why it was so difficult to implement, and indirectly foreshadowed where we would be today. However, amid the discusson, there was little action.
In 2012, .NET 4.5 brought us the `CallerMemberNameAttribute` type and its siblings, `CallerLineNumberAttribute` and `CallerFilePathAttribute`. These new attributes enabled developers to decorate method arguments, indicating that the appropriate piece of information was to be injected into that argument when the method was called. This fell short of an `infoof` operator, but it greatly simplified use of `INotifyPropertyChanged` (and `INotifyPropertyChanging`, introduced in .NET 3.5). Alas, argument exceptions, logging, debugging, and other uses of method, variable, and property names were left as they were, often leading to mismatched error messages, obscure data binding bugs, and other problems.
That changed in 2015 with the new releases of both .NET and C#, and the new `nameof` operator in C#6. The `nameof` operator is sublimely simple; in fact, its concept seems so obvious that it's a wonder it took so long to appear3. Using `nameof`, we can inject the names of variables, types, methods, events, and properties into all sorts of places at compile-time4, knowing that if we change the name, our refactoring tools can update all references with confidence. Not only that, but our intent is clear; we want the name of this thing to be here and not just some string that happens to look like the name of some thing. While the `nameof` operator does not replace `CallerMemberNameAttribute`, which so deftly simplified `INotifyPropertyChanged`5, it does simplify other scenarios like throwing `ArgumentException`, logging errors, and outputting debug information.
In Conclusion
When I first contemplated writing a whole blog entry dedicated to `nameof`, I thought it was too simple a feature to warrant such focus; now I have finished, I believe `nameof` to be entirely worthy of the attention. Along with the fantastic string interpolation in C#6, I believe `nameof` is one of the simplest and most useful additions to the C#6 language. Like many C# and .NET features we now take for granted, `nameof` is a beautifully simple concept that we will come to rely upon. I believe it will save us countless hours of fixing erroneous refactoring, arguing over coding style and code reviews, and head-scratching at spurious errors.
- IMHO [↩]
- pronounced, "Info Of" [↩]
- As is often the case in software development, we were all too busy discussing the most complex use-case we could think of rather than the one that really needed solving [↩]
- unlike reflection-based solutions that do all the work at run-time [↩]
- `nameof`Â does provide an alternative, more wordy alternative for that scenario [↩]