Interface Naming Notation - To "I" or not to "I"

While reading  R.C. Martin's book converted to C# by M. Martin "Agile Principles, Patterns, and Practices in C#" I could not ignore the fact that the Java notation for interface naming was used all over the place. Trying to be open-minded (or should I use "pragmatic" these days) I want to pop a question what is the benefit of dropping the I-prefix and how it does or does not influence the daily work.

For myself, having an "I" prefix in front of the name not only tells me that this is an interface, but also that this is a pure "contract" (Design by Contract is something I start to like). 

   1:  public interface ICustomer
   2:  {
   3:    // ...
   4:  }
 
   1:  public interface Customer
   2:  {
   3:    // ...
   4:  }

So what do you have to say about it? To "I" or not to "I"?

12 Comments

  • It has become a pretty standard notation across the organizations I work for.
    A couple of reasons that I think the "I" naming convention works well.
    1. When mixing the interfaces and classes in the same namespace it works as a differentiator.

    2. When having an Interface for Customer and a concrete object for Customer what do you call the class? ConcreteCustomer? I think it makes coming up about names easier when you have a convention like interfaces are named with "I".

    Jon


  • I prefer I because with intellisense all of the visible interfaces are all close together. that alone saves a lot of time.

    Also, it goes along with the whole "code for the next developer" mentality because I is the convention throughout the .NET framework, and is more discernable by another developer looking at your code.

  • Today many people think about Visual Studio and alikes when they talk about .Net code. But many a time, you may open the file in notepad or notepad++ etc. It makes a lot of sense having the "I" notation because looking at a piece of code, you are able to differentiate between a Class or Struct or Interface.

  • I also prefer the "I" prefix nameing convention.
    1. For intellisense
    2. For differentiation

    I've also read the same book and found the Java notation confusing at first.

  • Short answer: To "I".

    One and for me the most important reason: try to find different name for class and interface, so short like with one "I", so simple to fast understand aim of it, and so "standardized".

  • Even the Apple camp has converted to this notation long time ago, IMac, Ipod, Iphone, etc are interfaces in their own right. Google next :) IGooggle...

  • I also like the "I" naming convention, but how do you name a generic class based on an interface?

    See the example below. "ICustomerCollection" feels like an incorrect name because the collection itself isn't an interface.

    It also seems wrong to name it CustomerCollection because a "Customer" could be some completly different implementation not even inheriting from the ICustomer interface.

    public interface ICustomer
    {
    }

    public class ICustomerCollection : Collection
    {
    }

  • I value all the replies and comments. Wondering what would Java developers say about this.

  • I normally have and I in front of my interface. I feel it makes it easy to understand that this is an interface.

  • @JV

    this is exactly the reason I am bringing this question. It seems like in Java the name of the interface is always something that is a pure abstraction and concrete classes are the ones that are given names that would hint the fact that it's no longer an abstraction, but something real. Bicycle and AcmeBicycle would be a good example.
    I want to know what is the advocation for that notation. Seems like asking this question here is almost like asking a pack of wolves "should we eat sheep or not" - the answer for some reason will be "oh yeah!".
    Ok, i think wolves are coming for my soul once I wrote it :)

  • I think I is OK for interfaces.
    But I really don't like naming conventions for namespaces and functions. Camel should be better for them.

  • "I" is not cool........in java, smallTalk or ActionsScript. Interfaces give us polymorphism for an instance of a subclass. You are basically casting these subclasses to a common object that overrides super functionality. Lets be OOP and object oriented.
    Naming should follow function and not to confuse. So how about this.

    CustomerClass - superClass
    Customer - interface
    CustomerRetail - subClass
    CustomerWholesale - subClass
    CustomerOnline - subClass

    a= Customer(new CustomerRetail());
    b= Customer(new CustomerWholesale ());
    c= Customer(new CustomerOnline ());


    you really want to cast them to common sort of base functionality as to what they have in common.



Comments have been disabled for this content.