Tuesday, July 30, 2013

Why I Name Interfaces This Way

... Or, the article in which Jeremy disagrees with Uncle Bob.

So, I had a question recently on whether Hungarian notation is completely gone (or should be completely gone).  The answer is that it is "mostly" gone, but there are a couple of vestiges left in the .NET world.

For those unfamiliar with Hungarian notation, it's a naming scheme where we add prefixes that tell the type.  For example, "iCount" would indicate that this variable is an integer (from the "i' prefix).  The need for this has gone away with modern IDEs that give us easy access to types.  And it's also a bit easier for our brains to comprehend the meanings of the names if we keep extraneous letters out of the way.

Clean Code by Robert C. Martin (aka Uncle Bob) is an excellent book.  If you have not read this book, go do it now.  I'll wait.

Are you done reading yet?  I can wait some more if you want.

Uncle Bob's Recommendation
Here's a quote regarding naming Interfaces and Implementations:
"There are sometimes special cases for encodings. For example, say you are building an Abstract Factory for the creation of shapes. This factory will be an interface and will be implemented by a concrete class. What should you name them? IShapeFactory and ShapeFactory? I prefer to leave interfaces unadorned. The preceding I, so common on today's legacy wads, is a distraction at best and too much information at worst. I don't want my users knowing that I'm handing them an interface. I just want them to know it's a ShapeFactory."
Now, I agree with the principles in this recommendation.  If you take a look at my session Clean Code: Homicidal Maniacs Read Code, Too!, you'll definitely see that.

But as with all tools and recommendations, we need to look at our environment to see what is appropriate.

Why I Disagree Regarding Interfaces in .NET
I'm totally on board with eliminating as much cruft as possible, but there is one principle that I hold a little higher (and I think that Uncle Bob would agree with this one):

Do What Developers Expect

Also known as "following the path of least surprise."

In the .NET world (note: I'm only talking about .NET here), we have two primary examples of the vestiges of Hungarian notation: Interfaces and Generics.

The convention has been to name interfaces starting with a capital letter "I" (as Uncle Bob mentions).  The reason why I still name my own interfaces with a capital letter "I" is because that's what we're used to seeing in the .NET framework itself.

The .NET Framework Class Libraries have hundreds (if not thousands) of interfaces.  And all of them start with a capital "I".  (Now, I've heard that Microsoft is moving away from this, but that doesn't change all of the interfaces that are already in the framework.)  So, we have "IDisposable", "IEnumerable", "INotifyPropertyChanged", "IObservable", "IProgress", and hundreds more.

For better or for worse, this is what developers are used to seeing.  So, for the time being, I continue to follow this convention.

As mentioned, the other place we tend to see a prefix is in Generics (specifically generic type parameters).  If we look at the LINQ extension methods, we see all sorts of parameter names starting with a capital "T", including "TKey", "TResult", "TSource", "TElement", "TAccumulate", and many others.

From a technical standpoint, we can name our interfaces and generic parameters however we like.  The compiler doesn't care.  But people do.  So, for now, I follow the naming convention of doing what developers expect.  There are people who want to see the complete eradication of Hungarian notation.  If that gains traction, I'll be glad to follow it.

But until then, I'll follow the path of least surprise to make it as easy as possible for other developers to follow my code.

Happy Coding!


No comments:

Post a Comment