This is a subjective thing of course, but I don't see anything positive in prefixing interface names with an 'I'. To me, Thing
is practically always more readable than IThing
.
My question is, why does this convention exist then? Sure, it makes it easier to tell interfaces from other types. But wouldn't that argument extend to retaining the Hungarian notation, which is now widely censured?
What's your argument for that awkward 'I'? Or, more importantly, what could be Microsoft's?
The guideline doesn't explain why you should use the
I
prefix, but the fact that this is now an established convention should be reason enough.What do you have to gain by dropping the
I
prefix?It looks Hungarianish to me. Hungarian is generally considered a menace in strongly-typed languages.
Since C# is a Microsoft product and Hungarian notation was a Microsoft invention, I can see where C# might be susceptible to its influence.
In my opinion this 'I' is just visual noise. IDE should show class and interface names differently. Fortunately Java standard library doesn't use this convention.
I don't really like this convention. I understand that it helps out with the case when you have an interface and an implementation that would have the same name, but I just find it ugly. I'd still follow it if it were the convention where I am working, of course. Consistency is the point of conventions, and consistency is a very good thing.
I like to have an interface describe what the interface does in as generic a way as possible, for example,
Validator
. A specific implementation that validates a particular thing would be aThingValidator
, and an implementation with some abstract functionality shared byValidator
s would be anAbstractValidator
. I would do this even ifThing
is the only... well... thing that I'm validating, andValidator
would be generic.In cases where only one concrete class makes sense for an interface, I still try to describe something specific about that particular implementation rather than naming the interface differently to prevent a names collision. After all, I'm going to be typing the name of the interface more often than the name of the implementation.
Conventions (and criticism against them) all have a reason behind them, so let's run down some reasons behind conventions
Interfaces are prefixed as I to differentiate interface types from implementations - e.g., as mentioned above there needs to be an easy way to distinguish between
Thing
and its interfaceIThing
so the convention serves to this end.Interfaces are prefixed I to differentiate it from abstract classes - There is ambiguity when you see the following code:
public class Apple: Fruit
Without the convention one wouldn't know if
Apple
was inheriting from another class namedFruit
, or if it were an implementation of an interface namedFruit
, whereasIFruit
will make this obvious:public class Apple: IFruit
Principle of least surprise applies.
Not all uses of hungarian notation are censured - Early uses of Hungarian notation signified a prefix which indicated the type of the object and then followed by the variable name or sometimes an underscore before the variable name. This was, for certain programming environments (think Visual Basic 4 - 6) useful but as true object-oriented programming grew in popularity it became impractical and redundant to specify the type. This became especially issue when it came to intellisense.
Today hungarian notation is acceptable to distinguish UI elements from actual data and similarly associated UI elements, e.g.,
txtObject
for a textbox,lblObject
for the label that is associated with that textbox, while the data for the textbox is simplyObject
.I also have to point out that the original use of Hungarian notation wasn't for specifying data types (called System Hungarian Notation) but rather, specifying the semantic use of a variable name (called Apps Hungarian Notation). Read more on it on the wikipedia entry on Hungarian Notation.
I don't know exactly why they chose that convention, perhaps partly thinking of ensouling the class with "I" as in "I am Enumerable".
A naming convention that would be more in the line of the rest of the framework would be to incorporate the type in the name, as for example the xxxAttribute and xxxException classes, making it xxxInterface. That's a bit lengthy though, and after all the interfaces is something separate, not just another bunch of classes.