Why do we not prefix Enums, Abstract classes and Structs?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.