Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
I would vote for duplicate close, but the answer is on SO stackoverflow.com/questions/111933/… –  Euphoric Jul 23 '13 at 7:03
    
@Euphoric: This question is much more specific. –  reinierpost Jul 23 '13 at 7:56
add comment

2 Answers

up vote 13 down vote accepted

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

share|improve this answer
2  
+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 –  Binary Worrier Jul 23 '13 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 '13 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 '13 at 22:53
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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