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. 



Comments (39)

  1. Also, by using "I" and veering from class naming convention screams, "hey, stupid, don’t try and create an instance of this, ok?"

  2. Jakub Skopal says:

    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.

  3. Pavel Lebedinsky says:

    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.

  4. Bill Trowbridge says:

    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


    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.

  5. Andy Smith says:

    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.

  6. 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!

  7. moo says:

    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.

  8. Kevin Daly says:

    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#).

  9. Stephane Rodriguez says:

    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.

  10. 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

  11. moo says:

    Same for the C class thing thats no longer used much in C#.

  12. 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.

  13. James Avery says:

    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?


  14. Kevin Dente says:

    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?

  15. W Poust says:

    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.

  16. moo says:

    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.

  17. I think ICollection is more easily identifiable than CollectionInterface, so I’d say stick with the IXxx pattern.

  18. Louis Parks says:

    Since the design guidelines poo-poo using prefixes to indictate type (sz, n, txt, etc.), interfaces shouldn’t be prefixed either. However, what’s done is done. No sense crying over spilled milk.

  19. Wolfgang Al says:

    I come from a Java/CORBA (now C#) world, but I always use the I-prefix. It is clean, simple and widely understood. I strongly believe in using interfaces to boost flexibility. That means that the implementations themselves tend to be less important than the interface definitions. They should therefore be easily identifyable. If you are handed a typye library, you can at a glance see all the interfaces it defines…

    But like I said, I started programming in Java and I used a simple DOS Edit box for that. No IntelliSense whatsoever. So I am tainted beyond repair :). I also still use short type-prefixes for global variables for interface widgets such as txt for TextBox and lbl for Label. In my experience, this works very nice. Don’t use them for the rest though…

  20. Corrado Cavalli says:

    Look at this code:

    public class What: Guess



    Am I Implementing Guess or Inheriting from Gues?

  21. This is one of those purely cosmetic things that everyone has a strong opinion on, but which don’t really matter at all, of course.

    That said: The I thing is super-lame and makes .NET feel a bit old-school in that Hungarian way. And for no good reason at all, I feel more comfortable passing around a List in Java than I do passing around an IList in C#.

  22. Keith Patrick says:

    I’m one of those who is so used to seeing ‘I’ for an interface, that I miss interfaces when scanning code otherwise. However, it seems to be a whole lot like Hungarian notation, which is supposed to be no more, as IDEs are expected to provide the type. But then, Hungarian provides clues in the name as to a variable’s type, not what programming construct a type is.

    Personally, it would confuse the hell out of me to change it now (plus, I can’t endure reading any taunts from language zealots screaming "Hahahaha, MS admitted they were wrong, and we were right!"…IT’S JUST A NAMING CONVENTION!), and I think that the differences between an interface and a class are not the same thing as the difference between an int and a DWORD.

  23. Kevin Dente says:

    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. 🙂

  24. 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>?

  25. David James says:

    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".

  26. Alan McBee says:

    I favor condensation wherever clarity is not impinged.

    For example, I prefer "{" and "}" over "begin" and "end".

    How about a completely different stance? What about only using intransitive verbs or adjectives to name interfaces, rather than nouns or noun phrases? Just like there’s IDisposable, IEnumerable, or IPersistable, where "enumerable" is an adjective. This would probably lead to adding the "-able" suffix to a lot of verbs, possibly making up words in the process, but since when has that ever stopped us?

    ICollection –> Collecting

    IFormatProvider –> FormatProviding

    IAsyncResult –> AsyncResulting… AsyncResultant… AsyncResultable…

    Hmm. That sucks.

    I vote to keep the I prefix. 😉

  27. Doug McClean says:

    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.

  28. 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 🙂

  29. I find the "I" prefix very useful. The alternative, "XXXInterface", is clumsy.

  30. Kevin Dente says:


    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.

  31. ha says:

    > 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".

    That’s freaking hilarious!

  32. 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 =]

  33. Cathal Ryan says:

    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.

  34. James Bellinger says:

    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.

  35. Om says:

    * i find InterfaceCollection too long for an idiomatic only notation

    *interface is special cause from an object we can make multiple casting. at each notch of the inheritance tree path

    * Collection is something wrong: just consider class that implement simultanously




    should we read




    how should we handle interface % base % specialized layer in such a case?

    * the Editor only seems not sufficient cause when we want to publish, export it seems there will be a dead end

    * XxxBase

    think about button and the anymore hungarian notation:

    i obey and call now my ui ctl minText rather than textMin (ok cauze they only lie on surfaces), look how many folk do it not an half and it’s only in the ui layer. i bet you’ll introduce the mess for at least 5 years in .Net if you change the Ixxx naming convention

    my 0.1 €

  36. Dave says:

    I didn’t see anyone mention the helpful fact that using "ISomeInterface" allows Intellisense to group all of the interface classes together, so that you can find them.

    However, this is a hack, it’d be 100x better if IntelliSense would group interfaces, classes, attributes, etc into groups for selection, and filter out objects that don’t make sense in the current context (i.e. only show attribute classes when selecting an attribute).

    Although the poster that pointed out that IWhatever carries implicit knowledge of what it is/ how it’s supposed to be used in the name … so long as you follow the convention.

  37. Keith Hill says:

    An "I" prefix is a fine naming convention for interfaces in .NET. I also liked it in COM.

  38. 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.

Skip to main content