Framework Design Guidelines Class name prefixes

Continuing in the series of discussing topics from the Framework Design Guidelines


DO NOT give class names a prefix (e.g., C).


KRZYSZTOF CWALINA 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 regular type names. In majority of the cases

developers don’t care that something is an interface and not an abstract

class, for example.


BRAD ABRAMS On the other hand, the I prefix on interfaces is a clear

recognition of the influence of COM (and Java) 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.


JEFFREY RICHTER Personally, I like the I prefix and I wish we had more

stuff like this. Little one-character prefixes go a long way toward keeping

code terse and yet descriptive. As I said earlier, I use prefixes for my private

type fields because I find this very useful.


One thing I love about the annotation format is that it gives us a chance to share a wide range of view points on the guidelines.  While Krys, Jeff and I all agree that following the current guideline is a good idea, we have different views on what would (or would not) be better from one extreme (no prefixes) to the other extreme (lots of prefixes).   Where do you land?  

And what do you think of the format?  Do you find this kind of color interesting or distracting?

Comments (18)

  1. TAG says:

    How about generics type parameters ?

    I.e Dictionary<TKey, TValue> – not using prefix will cause name conflicts.

  2. Robert Kozak says:

    I think your blog is very well designed and the current color scheme looks great. Easy to read and good on the eyes.

    — Robert

  3. Shawn Oster says:

    Love the color and that’s mostly what I read the entries for. The guidelines are nice but without the color it would feel like yet another dry tomb-o-knowlodge.

  4. JoeW says:

    Don’t agree with Krzysztof. There is a clear difference between an abstract base class and an interface if the interface has been implemented explicitly. I don’t like prefixes at all in my code, but interfaces I think are the exception to the rule.

  5. Kevin Dente says:

    I’m with Krzysztof on this one. "Because COM did it that way" isn’t a good reason in my mind. .NET did away with lots of COM’s conventions – this one should have been no different. It’s just the last bit of Hungarian that survived.

  6. I wish C# would’ve inherited the "T" prefix for classes (types) from Delphi

  7. Chris Nahr says:

    I like the present .NET naming conventions, the flag the special cases (interfaces and generic type parameters) without cluttering up normal classes.

    "Framework Design Guidelines" is a great book, by the way. Not because I necessarily want to follow every single guideline (which I could get elsewhere anyway) but because it’s quite enlightening to see the rationale behind each guideline, concrete examples of what happened when they were not followed, and the different viewpoints of the original .NET architects.

  8. Jonathan Allen says:

    I like I prefix for interfaces because they aren’t like normal classes. They are more like attributes, a markers you apply to a class.

  9. orcmid says:

    I’m aligned with Chris Nahr with regard to naming conventions, and I use the I-is-for-interface even in Java (because they are really different). Of course, COM interfaces are in some sense "disguised" as abstract classes in C++, and it matters to emphasize that for casting the pointers, dealing with IUnknown methods, etc.

    I’m not lobbying, just noticing what has worked for me.

    I love the approach in the book, and in the blog, where different perspectives are offered in the commentaries. I just received my copy (now that you’re working on a reprint [;<) after hearing you present at the Seattle Code Camp and hadn’t dug in enough to realize that the book does that!

    I think the typography could have been done differently to make the commentary not so disruptive, and I think it is a terrific idea no matter what. The guidelines are much richer for it.

  10. David Stone says:

    Heck, the annotations in the book are half the reason I bought it and love reading through it. I like seeing the guidelines…but I love seeing the annotations on them that explain the parts that I’m interested in. 🙂

  11. Andrew Webb says:

    Definitely agree with Jeffrey that prefixes are good. The I prefix is a great help. And as we’ve seen the T prefix for generic type parameters (TKey, TValue, etc.) is a must-have to show that the symbol is a generic type parameter and not something else. All developers I know abandoned the Microsoft recommendation for naming fields, and use "_" or "m_". (Yes I know that this is roaming outside the original idea of not using the C prefix for class names, which is something I agree with.)

    I haven’t bought your book, but this little discussion (which interests me) has convinced me that I should! Buying now…

  12. I wish the self pointer had a shorter name in C# – like "me" in VB, that’d make me drop the prefixes for class fields. So far, however, I like using "_" or something to be able to tell locals from fields. The need for that is obvious –

    void Initialise(string name)


    _name = name;


    or something like that.

    No hungarian notation however – this is a thing of the past.

    I do also like the "I" prefix for interfaces.

    If you drop the prefix, you’d effectively blur the line between classes and interfaces. I disagree with KRZYSZTOF – developers do care about the difference between the two. Interfaces is something that can never be instantiated, they have different rules for inheritance and the design patterns for their creation is way different from those of classes’.

  13. Bart Elia says:

    I found the commentary discussion almost more valuable than the guidelines. Having intelligent individuals discussing the pros and cons to an aspect allows the reader to decide how to apply a rule for their environment.

  14. VBMan says:

    Plus it makes it more readable in C#, since you there is no Inherits or Implements keyword. How else would you know if you’re inheriting or implementing after the silly <classname>: WhatAmI 🙂

  15. AndrewSeven says:

    I’m surprised you are even asking the question. I thought it was a deliberate and well-planned style.

    The comments are what people will learn from. They will not be stuck with a set of rules without reason, they are given a something that will allow them to learn.

    By really learning it, the rules will become secondary points of reference.

    I like the I, it makes the difference clear. I’m leaning towards the T prefix for generic parameters, but for a while, I’ll just avoid making them public.

    I thought it was interesting that there was a dicussion about whether the interface could be considered a contract. The conclusion seemd to be "not really" but the next annotation called it a contract.

  16. Keith Patrick says:

    I’m very used to the ‘I’ format, but if the IDE colors the interface differently in the text editor, they’re close enough to a pure abstract class to where I could see not using the prefix any more to be consistent with the current trend in removing prefixing.

  17. andy says:

    I don’t like that classes ending in Class or Attribute can be referenced without the full name. So StringAttribute can be used like [String]. I never really understood the need for that. It saves typing, but it is just another wierd fact you have to remember when looking something up in the docs.

  18. PSC says:

    The "I" prefix for interfaces, e.g. ICloneable, is a useful convention as it resolves ambiguity.

    The additional conventions that I find useful, but not in the guidelines, are:

    1. Prefix local variables with l. (lIndex)

    2. Prefix parameters with p. (pName)

    3. Postfix pointers with Ptr. (lArrayPtr)

    4. Prefix generic type parameters with T.(TKey)

    Most others, e.g. C prefix for Class, m_ for fields, just seems like noise. (Many will claim even the above is unnecessary, but to me it just avoids ambiguity and name clash where there is potential for it.)

    I also always qualify identifiers with "this." for instance, or the Class name for static, references; not only because Intelisence then makes things easy but also because the code is clearer to read.

Skip to main content