Why do interface names begin with "I"

I am in the having one of those very useless “what-should-we-have-done” debates with a guy on my team and I thought I suck you folks into it. It is around naming of interfaces with an “I” prefix. Something COM founded (I think, does anyone know of an earlier example?) but java snubbed.

View one:

The only prefix used is “I” for interfaces (as in ICollection), but that is for historical reasons. In retrospect, I think it would have been better to use CollectionInterface as the name—it is clearer and follows the guidelines.

View two:

The “I” prefix on interfaces is a clear recognition of the influence of COM on the .NET Framework. COM popularized, even institutionalized the notation that interfaces begin with “I” Although we discussed diverging from this historic pattern we decided to carry forward the pattern as so many of our users were already familiar with COM.

Thoughts?

• Anonymous
  February 03, 2004
  Also, by using "I" and veering from class naming convention screams, "hey, stupid, don't try and create an instance of this, ok?"
• Anonymous
  February 03, 2004
  I came from Java world and was first a bit disgusted by this 'I'-thing in COM and C# world. Anyway, I started to like it. It's clear, short and with so common knowledge about it around - it's self-describing. And COM influence - it's definitelly COM influence, but anyway, any stable clear well-known naming-convention guideline is better than none.
• Anonymous
  February 03, 2004
  CollectionInterface looks stupid. After all, we don't have a HashtableClass.
  
  I think the ICollection naming scheme is just fine. It's simple, consistent and helpful.
• Anonymous
  February 03, 2004
  There are two conflicting forces at play here:
  (1) Our names should reflect the domain that we're programming.
  (2) We need unobtrusive semantic cues to deal with the programming language, types, and other information about our programming environment.
  
  Adding "I" or Interface to the name tarnishes it's domain meaning. If these semantic cues could be provided by the editing environment, we would not need them to be part of the name (unless we use another editor, too ... thus promoting exclusive use of the advanced tools). I think the "I" for Interface has survived (in an evolutionary sense) only because it's so important to know that a name refers to an Interface.
  
  SUGGESTION: It would be great if VS.NET introduced little superscript-prefix-icons to indicate the type and other language-related features of identifiers. To coin a word, let's call them "upscripts". Perhaps:
  Interface == circled-capital-I
  Integer == circled-small-i
  Class == semitransparent ballon with (possibly abbreviated) classname
  Double == circled-small-d
  Long == circled-capital-L
  etc.
  These upscripts would never need to be entered, but would automatically be presented before every instance of a name as the programmer enters type information, or other special language features. Color-coding and differently shaped icons could be used to indicate features such as WebMethod, Abstract, Shared, Public, Private, etc. Are you getting the picture?
  
  This is very similar to the function served by the "S" icon in the documentation which means "Shared" in VB, and "static" in C#. It's also a bit similar to the function of subscripts or superscripts or the "prime" character (X' == X-prime) in mathematics.
  
  The problem with using "Interface" spelled out is that it sometimes conflicts with domain naming. Does the name UserInterface refer to a language element Interface for a User, or does it refer to what we call a User-Interface? But (I)User could be clearly identified as an Interface for a User, not a User-Interface.
  
  In the future, let's get help from the tools for the semantic cues about the language, and leave the names to express what we know about the domain.
• Anonymous
  February 03, 2004
  The only annoyance I have found, is that it's awkward, at best, to have an interface that starts with the letter I, because the double-I is hard to read and understand.
• Anonymous
  February 03, 2004
  I like the "historical influence" on the naming issue of interfaces. I'm not an old time Windows developer but I like this way, 'cause I come from Java and I kept too much time in finding the rigth interface for the rigth job. In Java there are, even, interfaces with the same name of classes :( Bad, very bad in my opinion. Bye!
• Anonymous
  February 03, 2004
  Like all aspects of development, you can do what suits you best. Nobody forces you to use the I prefix on interface names just as nobody forces you to use the C prefix on Classes.
  
  Development is about providing solutions for your problem domain, do what works best for you.
  
  
• Anonymous
  February 03, 2004
  I like the "I" naming convention for interfaces, primarily I think because the contexts in which interfaces are used mean there is a lot of scope for confusion with classes otherwise (including the syntax for indicating implementation of an interface in C#).
• Anonymous
  February 03, 2004
  
  I'd love to see a text editor with graphics or formatting styles surrounding an interface name, or any other key "object" of the source code. An RTF editor could handle that just fine. The whole point of it is : quick glance.
  
• Anonymous
  February 03, 2004
  Objective #1 for a convention is to be wildely known and adopter/used by the majority. That's the case with the I-thing.
  
  Now, you may have endless discussions to know if that's the best (if any?) way to do it...
  
  My $0.02
• Anonymous
  February 03, 2004
  Same for the C class thing thats no longer used much in C#.
• Anonymous
  February 03, 2004
  I've never been a big fan of the argument that Bill Trowbridge puts forward - that these things should be solved by UI cues in the IDE. But then maybe I'm the only person in the world who still prints stuff out to do code reviews... (I find I catch errors I would never see on screen that way. I've no idea why. It's the same for prose. Worse in fact - I always find a host of errors that were previously invisible to me when I print out.)
  
  Bizarrely, I happen to like the I prefix, but not the old C prefix. I think this is because it's usually pretty obvious from the combination of PascalCasing and context when something is a class name as opposed to the name of something else. But without the 'I' convention it would be harder to distinguish between interfaces and classes.
  
  In general, I find that C# source that conforms to the naming guidelines is usually fairly easy to parse as a human without resorting to looking things up or relying on intellisense popups. I think that's a good thing even if you do live entirely in the IDE - relying on popups is tedious, and lots of extra adornment graphics would, I suspect, make it harder to read.
• Anonymous
  February 03, 2004
  Putting something at the end of the name does not do me much good, when I am looking at a long list of classes I am usually looking at the front of the name, so in this case 'I' does the trick as I can quickly identify an interface.
  
  Also, if you changed it to something else then how would all these people come up with there cute little blog names?
  
  -James
• Anonymous
  February 03, 2004
  I definitely wish the "I" prefix hadn't made its way into the framework, for a couple of reasons. The first and most obvious one is just consistency with its own conventions.
  
  The second is that I don't see why an interface needs to be identified as "special". We don't prefix value types, static classes, generics, or abstract classes, even though, like interfaces, they are semantically different from standard classes. Let the compiler tell me what's legal to create, I don't need a naming convention for that.
  
  Rather than ICollection or CollectionInterface, I would have just preferred Collection. When I pass one of these things around as an argument, I don't really care if it's an interface or a class, it's really just a bunch of state and behavior that I want to interact with. When I'm talking to it, why do I care if it's an interface or a class?
  
• Anonymous
  February 03, 2004
  The "I" prefix is ok but can be a bit confusing when you start dealing with projects to have a lot of COM interop. For instance, you have a Stream class that doesn't implement the IStream interface. How many of us have implemented somekind of COM stream object that implements that interface. Old habits die hard.
  
  Another option would be to group the interfaces in there own namespace (something like System.Interfaces). I don't know if I want to endorse it, but its a thought.
  
• Anonymous
  February 03, 2004
  You DONT HAVE to use it, its just a name, you can call your interface Bob for all it cares.
  
  Nobody is twisting your arm to use it.
  
  
• Anonymous
  February 04, 2004
  The comment has been removed
• Anonymous
  February 04, 2004
  The comment has been removed
• Anonymous
  February 04, 2004
  The comment has been removed
• Anonymous
  February 04, 2004
  Look at this code:
  
  public class What: Guess
  {
  
  
  }
  
  Am I Implementing Guess or Inheriting from Gues?
• Anonymous
  February 04, 2004
  The comment has been removed
• Anonymous
  February 04, 2004
  The comment has been removed
• Anonymous
  February 04, 2004
  Corrado - that's why Java differentiated between derivation and implementation, using extends vs implements. I actually thought that was quite a nice idea, and wish the framework had adopted something similar.
  
  Of course, Keith is right - too late to change it now. But sometimes it's nice to grumble about what might have been. :) After all, some day something will replace the .NET framework - maybe they can fix it then. :)
• Anonymous
  February 04, 2004
  I'll second the notion of clarity and brevity. "CollectionInterface"? Ugh. Just because I type fast doesn't mean I want to type more. Paying homage to COM is a non-issue - the distinction between a class and an interface in a compact and easily identifiable form is the main benefit.
  
  Now, what happens when generics come? Ever needed a typesafe sequence of similar items, sort of like a string of them? so the generic would be ... GString<T>?
• Anonymous
  February 04, 2004
  I think most naming conventions are learned by people seeing how the Framework names things and imitating it, not by reading a design guide.
  
  A couple of programmers on our team learned that interface names should begin with "I", but didn't pick up on the rest of the guidelines. So they treated "I" as a personal pronoun, not as an acronym. We now have interface names like "IAmAChildObject", "INeedMyDataRow", "IAmDependentAndWantMyParentCollection", and "ICanDeleteMyself".
  
• Anonymous
  February 04, 2004
  The comment has been removed
• Anonymous
  February 04, 2004
  I favor the "I" prefix because it prevents name collisions with a default implementation of the interface, which is fairly common. By way of example, my work today on software for educational examinations is based on an IQuestion interface, for which a Question class serves as a default implementation in most cases. Without the prefix these names would collide.
• Anonymous
  February 04, 2004
  Kevin Dente observes that most other entities don't get special prefixes to call them out. and he has made me realise that I really wish value types were called out in a similar way. (So I take back my earlier comment about everything being resonably clear from context. Almost everything is reasonably clear from context, but I do sometimes find myself having to take steps to find out whether I'm dealing with a class or a struct...)
  
  As for his other examples... I'm not sure what he means by a static class. (I know what a static inner class is in Java. But since C# doesn't have an equivalent to Java's non-static inner classes (nested C# classes are like Java static inner classes) there isn't really any need to distinguish them...)
  
  Generics? I think the angle brackets are going to make those pretty obvious aren't they? So those are called out too.
  
  Abstract classes? An interesting one. I guess I don't care much about these because it has been so long since I saw one. :-)
  
  Thinking more about this, the thing I really like about the I prefix is that it screams "polymorphism" at me. It makes it completely clear that I can't make assumptions about what class I'm dealing with. (But then I don't really like abstract base classes, so in my world, polymorphism always implies interfaces. However, I know that Brad doesn't like interfaces as much as me. So I understand that my personal reasons for liking this style won't necessarily work in everyone's world view.)
  
  And I still don't buy the IDE argument. Yes it's easy enough to press Ctrl-K, I to find out what you're looking at (except for those bizarre occasions where it refuses to tell you). But that puts a massive obstacle in your way - if you can just tell by looking, it lowers the cost of discovering what you're looking at, which is less distracting, which makes it easier to understand what you're looking at. I think the more readable code is, the better chance you have of getting it right, so anything that enhances readability is a good thing. (But that's not an argument in favour of Hungarian notation in general - there's a difference between a smattering of well-known single letter prefixes, and a limitless variety of multi-letter prefixes. Somewhere between those two points, the net contribution to readability flips from positive to negative.)
  
  -- Ian
  or is that -- IAn
  or maybe -- IAnEx
  -- IAn2 :-)
• Anonymous
  February 04, 2004
  I find the "I" prefix very useful. The alternative, "XXXInterface", is clumsy.
• Anonymous
  February 04, 2004
  Ian,
  By "static classes" I mean the new Whidbey keyword which marks a class as sealed, non-creatable, and having only static members. You got me on the generics, though. :)
  
  You said "It makes it completely clear that I can't make assumptions about what class I'm dealing with.". Can you give some examples of how your code might be different based on whether you're dealing with an interface or a class? For example, what kind of assumptions do you make about a class instance vs an interface instance? How about with a value type? Have there been times when you didn't "get it right" because you didn't know you were dealing with an interface rather than a class? Trying to grok, here.
• Anonymous
  February 05, 2004
  The comment has been removed
• Anonymous
  February 06, 2004
  I like it because it was taken from COM, but more importantly it gets the point across by a quick glance. It also requires less typing and I am lazy =]
• Anonymous
  February 07, 2004
  It's definitely too late to change now, but I like using I as a prefix because I usually perform manual code reviews using printouts.
• Anonymous
  February 08, 2004
  In .Net, most everything is a class. Interfaces operate a little differently so it's nice to be able to easily differentiate them from classes. Also it helps for finding them in IntelliSense (when I'm looking for an interface I know I'm looking for an interface, and without the I it would be harder to find them -- hypothetically, anyway, since I only use a few). Classes are the norm so they don't need a prefix.
• Anonymous
  February 08, 2004
  The comment has been removed
• Anonymous
  February 09, 2004
  The comment has been removed
• Anonymous
  February 09, 2004
  An "I" prefix is a fine naming convention for interfaces in .NET. I also liked it in COM.
• Anonymous
  February 10, 2004
  I personally don't think either View1 or View2 are excellent reasons for using/not using the I prefix for interfaces. With regards to View2 my experience with COM has been of little benefit to me in understanding dotnet and I didn't get a warm and Fuzzy feeling when I saw it there. Ultimately, I could have went both ways. With regards to View1 its sticks to the guidelines but perhaps it shouldn't. With that said here are my thoughts.
  
  I think having an "I" prefix for interfaces makes the code more easily readable especially when inheritence is used. Also I strongly agree with Ian in that the I for indicating interface makes me immediately aware of polymorphism usage in the most straight forward way I can imagine. Obviously adding the word interface to the end would accomplish this but it is way to long for such a common distinction. There should be a common prefix for structs too. However, there shouldn't be a prefix for all types because it clutters up the true intention for the code.
• Anonymous
  June 18, 2009
  PingBack from http://homelightingconcept.info/story.php?id=2798