The C# community has so ubiquitously used the "I" prefix to denote an interface that even the most inexperienced programmers know to use it.

Why is it then that we do not prefix enums, abstract classes or structs (possibly with "E", "A" and "S" respectively)?

For example, if we did mark all abstract classes with an "A", it would provide valuable information about that type which, while it could be inferred, is not immediately obvious.

Please note that I am not advocating for this change, I am merely trying to understand why we do not do things this way.

This thread answers why we do use the "I" prefix but doesn't answer why we don't use other prefixes.

  • 3
    I would vote for duplicate close, but the answer is on SO stackoverflow.com/questions/111933/…
    – Euphoric
    Jul 23, 2013 at 7:03
  • 1
    @Euphoric: This question is much more specific. Jul 23, 2013 at 7:56
  • Possible duplicate of What is the benefit of not using Hungarian notation?
    – gnat
    Jun 21, 2017 at 22:10
  • IMO Enums should be avoided (replaced with public static readonly members (enum pattern)), abstract classes should have "base" suffix, and structs should have had lower case as a naming convention, but since .NET doesn't do that, it just gets confusing if you make structs lower case, since it will never be consistent. Dec 3, 2018 at 19:13
  • Why would you avoid using enums in favour of creating psuedo enums?
    – Stephen
    Dec 3, 2018 at 23:54

3 Answers 3


The point of the naming convention for interfaces is to provide a quick, no-brain decision about what to call the interface that your class implements. If you have a Frobnicator, but have to declare an interface for decoupling or whatever reason, then the decision to call it IFrobnicator requires no conscious thought, and this is good.

The same problem doesn't apply to the other constructs you name. Enums and structs are useful, but it's not necessary to find a second, short, transparent, obviously related name in addition to the name itself. Therefore, there is no pressure to slap an 'E' on to the name of an enum or struct.

(Abstract classes are somewhat similar to interfaces, since you do have to provide a second, concrete class to get anything done, so they might have acquired a convention of starting with 'A', but for whatever reason, they didn't. If I'm allowed to speculate, I think that 'I' being a particularly narrow letter might have had something to do with that.)

  • 5
    +1 This is the answer I would have written. I'd point out though that abstract classes already have a perfectly cromulent naming convention, where the abstract class is named AnimalBase and distinct flavors are AnimalGiraffe, AnimalLion etc Jul 23, 2013 at 7:58
  • It may be worth mentioning many Java interfaces don't use 'I', like List, since the very technically-named ArrayList and LinkedList are the names of the implementations. (C#, I believe, has IList as the interface, and List as the array list)
    – Katana314
    Jul 23, 2013 at 13:52
  • I wonder if it might have been helpful, way back when, for Microsoft to have recommended that variables of "mutable" structure types be given a particular prefix, to avoid confusion about whether Point p = myPoints[3]; p.X += 3; would affect myPoints[3].X. Retrospectively, I would have preferred that C# use var->field for class-field access and var.field for struct-field access, but obviously it doesn't. Still, it would seem some at-a-glance means of distinguishing them would be helpful.
    – supercat
    Dec 23, 2013 at 22:53

I think it isn't used much because:

  • most of the time it doesn't mater much if it is an enum, or an abstract class or a struct
  • if it does mater I can probably see it from usage and otherwise find out pretty quickly
  • if I change it being an enum, abstract class or struct , I also have to rename it
  • for people who don't know the convention it is pure noise.
  • people might just dismiss the entire idea because they have been taught not to use Hungarian notation. There have been and still are people who say you should not use Hungarion notation, without making the distinction between Apps Hungarian and Systems Hungarian. A nice discussion can be found in this SO question. Not just the first answer is interesting but there are great answers and comments. From that same question comes this article by Joel Spolsky (scroll to paragraph "I’m Hungary" )

in short : In general the added value doesn't add up to the cost.

From that last bullet point and some interpretation you could conclude. Systems Hungarian (prefix type) is bad and should not be used. Apps Hungarian (prefix kind) has it uses.

Taking that back yo your question I think your proposed notation is a form of Apps Hungarian and if you feel that the added value adds up to the costs and you implement it consistently in your code base it is just fine. But since you have to consider it on a per project basis it should not be a general rule.

I guess people noticed that it did mater for interfaces more often and that is why it has become a general rule for interfaces.


Just a (hopefully applicable) thought:

There is an obvious trend toward 'coding to interfaces' rather than concrete classes. "Nowadays" it almost seems more beneficial to have a naming convention for the classes, like starting them with a 'C', rather than having the letter 'I' for the interface.

I just ended a Java project in which all of the Interfaces were actually called Model.. Yep, the interface name convention was to end the name with 'Model'... then have some kind of 'DataTransferObject/DTO' implement the interface as:

public interface SomethingModel{

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line

whereas in C#

public interface ISomething{}

public class SomethingModel : ISomething
   //i can read this

Rewiring my brain to keep that straight hurt, but I can see how it might help to think it terms of programming to the interface.

Not the answer you're looking for? Browse other questions tagged or ask your own question.