What’s the reasoning behind the “I” prefix naming convention for interfaces in .NET

namingnet

I know the "I" convention has been around since COM, but I've never understood why it hasn't been reconsidered like every other naming convention before .NET has.

Consumption wise, the only thing that separates an interface from, say, an abstract class, is that they can be multiply inherited. But everything after Visual Studio 2003 has shown type signatures in tooltips, so it's as useless as all the other Hungarian notations that have been discarded.

I also thought it might be so that you can have a basic implementation of the interface with the same name, e.g. Message inheriting IMessage, but most of the .NET libraries have gone for adding the word "Base" at the end (e.g. System.Collections.ReadOnlyCollectionBase) instead — and this makes more semantic sense.

COM interop seems to be another possible reason — but it's not as if the wrapper classes that it generates are perfectly idiomatic .NET, so I doubt that that was an aesthetic consideration.

In one of my newer projects I've forgone the convention entirely, and it feels just fine. Is there something I'm missing?

Best Answer

I think this may well be the only case when prefixes are useful.

Classes and interfaces really do have different semantics, and because both are types, are easy to mix up.
When I see a class declaration, I can instantly tell what it derives from and what it implements:

public sealed class ActivityCollection : List<Activity>, 
    IList<Activity>, ICollection<Activity>, IEnumerable<Activity>, 
    IList, ICollection, IEnumerable

It would be harder to understand if the definition looked like

public sealed class ActivityCollection : ListClass<Activity>, 
    List<Activity>, Collection<Activity>, Enumerable<Activity>, 
    List, Collection, Enumerable

And how would you call ListClass? Clearly it's not just ListBase because it's usable on its own.
So, we either have to solve a problem we just invented, or adapt a prefix that separates classes from interfaces, which is what .NET Framework designers did.

Also, personally I find it useful when I can tell from the method signature that it works with interfaces.

public void PrintLines (IEnumerable<string> source)

It's like a signal to my head: hey, I can implement this! I can feed the method whatever matches the contract.

Of course one can argue it's not that important but this is one of those little things that make the prefix worth it for me. It's especially useful when writing a lot of code with IoC containers when you constantly work with interfaces and need to easily differentiate between the two.

By the way, not only the interfaces have prefixes in .NET type system. Don't forget about the generic type parameters:

public delegate TResult Func<in T, out TResult>(
    T arg
)

This is another situation when it's extremely useful to be able to differentiate between classes and another kind of types.

Related Topic