The last vestiges of Hungarian notation

Certain arguments seem to resurface every few years, like whether or not to use a mocking framework, and more recently on Twitter on why .NET still uses Hungarian notation in a few select cases, namely:

  • Interfaces
  • Generic type parameter names

The argument against Hungarian notation in these cases is that it adds nothing to the equation, and is not self-consistent. We don’t prefix Enums with “E”, classes with “C”, structs with “S”, delegates with “D” and so on. Why are these two special?

I’ve seen perfectly valid arguments on both sides on why these two have special rules, and personally, it’s never really bothered me. But for .NET, those arguing that we should ditch Hungarian for these two cases are missing the point.

The train for picking different naming styles for interfaces and generic type parameter names left the station a long, long time ago. That ship has sailed. Picking a different naming convention that goes against years and years of prior art, established conventions and expectations is OK if you’re the only one who’s ever going to look at your code.

If you do decide to ignore a decade of convention, you’re also deciding to irritate and confuse every .NET developer that reads your code when you’re done. Because every time someone else sees that interface without the “I”, the question will always come up on why that decision was made. Unless you’re just a complete sadist, just stick with the convention, please?

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Rant. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Rennie Petersen
  • William Green

    Simply put, it is idiomatic .NET to prefix interfaces with I and type parameters with T

  • Lee Brandt

    The thing is, I think a lot of .Net programmers end up missing the power of interfaces because they are used to seeing IWhatever interface and a Whatever implementation. They end up not seeing what interfaces bring to the table. However, it is not the most important fight, so I tend not to bother.

    http://disruptivetheory.com/2011/04/28/dropping-the-i-from-interfaces/

    • http://www.daedtech.com Erik

      I think that’s an excellent point.  I was a Java programmer before a C# programmer, and I used to name my interfaces things like “CustomerDao” and the implementers things like “CustomerDaoMySqlImpl” or “CustomerDaoSqlServerImpl”.  

      After that, I took a job in a C# shop and saw that interfaces were used sparsely, and when they were, it was always “IFoo” and “Foo : IFoo”.  I got the sense that these interfaces were implemented specifically to circumvent compiler complaints or to “decouple” as a best practice, without really understanding the power of the interface.  It’s almost as if interface/implementer is similar in concept to people as the “partial class” paradigm — just two parts of a whole.

    • http://codekaizen.myopenid.com/ Guest

      While this is true for the .Net developers who don’t have a strong understanding of the importance of interfaces to define public boundaries of abstracted responsibility in systems (and, yes, there are a lot of them), there are others which very much do understand this. If you avoided being trapped by the oversimplifications of VB 5 and 6 or came from C++ COM, you brought with you the understanding of the interface, but named them with an “I”. I went from COM to Java and had a hard time finding the public interfaces to a system since there were no “I” markers. While I can appreciate removing the naming distinction and thinking of the abstraction first and the implementation second, I liked following the “I” to get a quick understanding of the boundaries of the system. In a way, Java does this by putting “Impl” at the end of concrete classes. You just can’t sort on it and scan that way.

  • http://muddypa.ws nportelli

    I just don’t get the argument either way. Personally I like the ‘I’. It’s one of those convention things. If I didn’t see it? Well who cares. Why get your panties in a twist over something so trivial? Now if it is just a poor name, like ICatWhoBarks then I can see the rage.

  • http://twitter.com/chriso Chris Ortman

    The way I understand uncle bob’s point about ‘I’ is that it communicates a detail that should not matter to the consumer of the code…which I kinda get if I have Customer or ICustomer it should not matter to me when I call the MakePreferred method.

    But there is one time where it does matter. I can’t var c = new ICustomer(); 
    So the ‘I’ prefix at least guides me to the fact that I shouldn’t be trying to new this thing up so I still prefer to use ‘I’ in front of interface names

    Having the T on type parameters though I don’t see any value to it so for consistency I think it should be dropped.

    I think it was StructureMap or FluentNHibernate code where I first saw ALL_CAPS descriptive names for type parameters. I thought that MODEL was much easier to follow that TModel
    Probably just a preference.

    • Anonymous

      If it was the .NET idiom to not have the I, I’d do that. I get the arguments, but it’s just too late now.

      But man, those ALL_CAPS generic type params are just awesome.

  • Onemoments
  • http://ckramer.myopenid.com/ Casey Kramer

    Interestingly, while I tend to use the I prefix for interfaces in .Net (mostly due to years of brain washing early on), I almost never add any sort of prefix when I’m using Traits in Scala.  For some reason the fact that they can have implementation attached to them makes it feel “wrong” (even if there is no actual implementation).  I’ve also never entertained the thought to using a T-prefix on a trait.  I think a big part of this is due to the fact that the examples I saw while learning the language did not use any such convention, so it clearly is not an idiom used in that space.  Contrast that with the use of the I-prefix on every interface in every piece of even somewhat “official” C# example code.

  • Chris Bristol

    From a purely preference standpoint, I prefer that interfaces be named something-able, like Comparable, Enumerable, etc… without the “I” prefix. On the other hand, I completely agree with you about following the conventions of the language you are using.  In .Net I name all of my interfaces as ISomething, and generic type parameters are TWhatever.  If I were writing in Java, I would name them consistently with its conventions.

    The point of code is to communicate, and when you go against established and accepted (tolerated?) conventions you lose a lot in translation. Conformity isn’t always bad, and tolerance doesn’t mean that you like something.

  • Anonymous

    For any conversation about Hungarian Notation, I think Joel Spolksy’s post discussing what Simonyi really meant is useful reading. It rolls back some of the Hungarian Notation hate and reframes the conversation from ”OMG, you’re still using Hungarian?”: http://www.joelonsoftware.com/articles/Wrong.html

    If you read Joel’s explanation, Simonyi’s intent was not that you prefix names with the name of their class or primitive ‘type’, which is useless, but with a prefix relevant to your domain that tells you something important to remember about that particular object. Joel’s example about unescaped, unsafe strings versus escaped strings is a good illustration. It’s really just a specific case of the idea that “names should describe what things are.” And in that form it’s not stupid.

    In .NET, I’m partial to the IFoo convention because it lets me know to look for a class factory or an IoC container rather than trying to new up an IFoo. This is useful information to have about a type. Nothing I couldn’t figure out on my own, but it’s nice not to have to. I might just be rationalizing a defense of something that I’ve grown used to, but I do find myself missing the convention when I look at interfaces in Java code. Admittedly I don’t do a lot of Java.

    Agree with Jimmy’s point that the ship has sailed on these conventions anyway. Wasn’t aware that this discussion was even happening!

  • Asker

    What do you think about those “role based interfaces” that look like IHaveProducts or IAmRidiculous?

    • Lee Brandt

      I like the idea of something similar where I is a proper noun like IGetProducts or IReadConfiguration.

  • http://truewill.myopenid.com/ Bill Sorensen
  • Slo

    I think one should stick with the convention of a language or platform he/she is working with. For me the “I” thing adds to readability of code, for instance if you say class SomeClass : IDisposable { … }, for me it reads like “I am Disposable”, or Enumerable, Comparable or similar. I’m quite confused in Java what is an interface, because you don’t see it immediately.

  • Anonymous

    I usually skip the I when I define NServiceBus business events just to not confuse the business guys. But that is of course the mother of all special cases:)

  • http://twitter.com/PhatBoyG Chris Patterson

    IAgree the argument is long over. If IBothersYou, don’t use it. Personally, IAmAnnoyedByIt, so IDontUseIt on my interfaces.

  • Pingback: DaedTech

  • Laurent

    …a logical fallacy known as “Appeal to Tradition”: “This is the way we’ve always done it. Therefore, it is the right way”.

  • Anonymous

    Idiomatic != recommended!

    The arguments in favor of role-based naming of abstractions are very strong and very much in line with good design (including Martin’s “SOLID” OO-subset).

    Teach people to do what’s best, and don’t compromise your own work.  Compromising your own work compromises the community as a whole.  You have open-source projects. . . make them beacons of what should be — not what happens to be.

    I recently have taken steps to stop mutating variables in Java.  This is not idiomatic in the Java ecosystem. . . but it is almost always better.  I also started using Option monads in place of nulls (again, not idiomatic, but superior).  Serious defects are avoided with this approach.  On a lighter note, I also stopped using “get” prefixes on property accessors, because it’s stupid (although it is idiomatic).

    Make your own idioms, if they are superior.  Ecosystems worth being in should have enough users bright enough to appreciate improvements.