Interface naming convention

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?

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 interface IThing 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 named Fruit, or if it were an implementation of an interface named Fruit, whereas IFruit 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 simply Object.

  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.

The reason I do it is simple: because that's the convention. I'd rather just follow it than have all my code look different, making it harder to read and learn.

Well, one obvious consideration would be the (very common) IFoo and Foo pair (when abstracting Foo), but more generally it is often fundamental to know whether something is an interface vs class. Yes it is partly redundant, but IMO is is different from things like sCustomerName - here, the name itself (customerName) should be enough to understand the variable.

But with CustomerRepository - it that a class, or the abstract interface?

Also: expectation; the fact is, right or wrong, that is what people expect. That is almost reason enough.

Thing is more readable name than IThing. I'm from the school of thought that we should program to interfaces rather than specific implementations. So generally speaking, interfaces should have priority over implementations. I prefer to give the more readable name to the interface rather than the implementation (i.e., my interfaces are named without the 'I' prefix).

I'm sure your question was the topic of many lengthy discussions within the Microsoft team that worked on the .NET Framework and its standards.

I think the most telling example comes from the source itself. Below, I transcribe extracts from [Framework Design Guidelines][1], a book I highly recommend.

From Krzysztof Cwalina, CLR program manager: > 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 a majority of the cases developers don't care that something is an interface and not an abstract class, for example.

From Brad Abrams, CLR and .NET Framework program manager: > 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.

From Jeffrey Richter, consultant and author: > 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. [...] I use prefixes for my private type fields because I find this very useful.

My point is, it WAS on the discussion table. An advantage I see is that it helps avoid name collisions between classes and interfaces, so your names can be both descriptive and compact

Personally--and perhaps out of habit--I like the I prefix, because it succinctly flags interfaces, allowing me to have one-to-one naming correspondence with implementing types. This shines in cases when you want to provide a base implementation: IThing is the interface, Thing is the base (perhaps abstract) type. Derived types can be SomeThing. I love being able to use such crystal clear shorthand notation.

[1]: http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613 "Design Framework Guidelines"

I think it is better than adding a "Impl" suffix on your concrete class. It is a single letter, and this convention is well established. Of course you are free to use any naming you wish.

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.

There is nothing wrong with NOT using I convention for interfaces - just be consistent and make sure it works not just for you but for whole team (if there is one).

Because you usually have an IThing and a Thing. So instead of letting people come with their own "conventions" for this recurring situation, a uniform one-size-fits all convention was chosen. Echoing what others say, the de facto standardness is reason enough to use it.

It's just a convention that's intent is to prevent name collisions. C# does not allow me to have a class and an interface named Client, even if the file names are Client and IClient, respectively. I'm comfortable using the convention; if I had to offer a different convention I'd suggest using "Contract" as a suffix, e.g. ClientContract.

Naming an interface should have much deeper meaning than just whether or not you put an "I" at the front of the name.

Neither "Fruit" nor "IFruit" would have a whole lot of meaning for me as an interface. This is because it looks a lot more like a class. Classes define things, whereas interfaces should define functionality.

The "I" naming convention does help differentiate between classes and interfaces so that development is a little bit easier. And while it is not required, it certainly helps avoid common object oriented coding headaches. C#, like Java, only allows for inheritance from a single base class. But you can implement as many interfaces as you want. The caveat is, if you inherit from a class and implement one or more interfaces, the base class has to be named first (i.e. class Trout: Fish, ISwimmer, IDiver ... ).

I really like to name my interfaces both based based on what functionality they provide as well as what type of interface they are (i.e. animate or inanimate interfaces).

If you focus on in functionality that the interface provides you can quickly determine a name for the interface. It also helps you to quickly see if your interface defines unrelated functions.

Interfaces that define inanimate objects (i.e. things that can't act on their own)... I like to name them with ...able at the end IPrintable (such as Document, Invoice) IPlayable (such as Instrument, MediaPlayer) ISavable (such as Document, Image) IEdible (such as Fruit, Beef) IDrivable (such as Car) IFlyable (such as Plane)

Interfaces that define animate objects (i.e. things that act on their own)... I like to name them with ...er at the end ISwimer (such as Fish, Dog, Duck) IDiver (such as Fish, Duck) IFlyer (such as Pilot) IDriver (such as NascarDriver)

In the end, the "I" naming convention helps differentiate between interfaces and classes. But it may make sense to add additional naming logic besides just the "I" at the beginning.

> Do prefix interface names with the > letter I to indicate that the type is > an interface.

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.

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.

I know the Microsoft guidelines recommends using the 'I' to describe it as an interface. But this comes from IBM naming conventions if I'm not remember wrong, the initiating 'I' for interfaces and the succeeding *Impl for the implementations.

However, in my opinion the Java Naming Conventions is a better choice than the IBM naming convention (and not only in Java, for C# as well and any OO programming language). Interfaces describes what an object can be able to do if it implements the interface and the description should be in verb form. I.e Runnable, Serializable, Invoiceable, etc. IMHO this is a perfect description of what the interface represents.

It's popular for an OS GUI to use different icons for files and folders. If they all shared the same icons, but folders were prefixed with "F", it would be acceptable to use the same icon. But, since humans' image recognition speed is faster than their word recognition speed, we have settled on icons.

Computer programs like IDEs are fully capable of making a file's interface-ness apparent. This would free the namespace of different levels of abstraction happening in the same name. E.g. in "ICare", "I" describes the implementation and "Care" describes the interface's capabilities.

I'm guessing the "I" convention is so popular because we haven't been able to think of anything better, but it's existence is important because it points out a need we have for knowing this kind of information.

To separate interfaces from classes.

Also (this is more of a personal observation than dictated from upon high), interfaces describe what a class does. The 'I' lends itself to this (I'm sure it is a construct in grammar which would be great to whip out right now); an interface that describes classes that validate would be "IValidate". One that describes matching behavior would be "IMatch".

The fact of the matter is that everyone understands it and part of writing better code is making it easy to read and understand.

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 a ThingValidator, and an implementation with some abstract functionality shared by Validators would be an AbstractValidator. I would do this even if Thing is the only... well... thing that I'm validating, and Validator 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.

You may add the word "Interface" as a suffix to your customized interface for example "SerializerInterface". For abstract class, "Fruit", for instance, "FruitAbstract" or you can make it "AbstractFruit", just be consistent all through out. That is readable enough, or follow the usual naming convention.

Just my 2 cents:

The reason why I personally append the suffix "Interface" is because it is easier to read than the "I" prefix and because the files in the system are listed "grouped". For example:

Not so good:

Alien.php
Host.php
IAlien.php
IHost.php
IXenomorph.php
Xenomorph.php

Better:

Alien.php
AlienInterface.php
Host.php
HostInterface.php
Xenomorph.php
XenomorphInterface.php

But that's just personal taste. I think as long as one uses a consistent naming convention throughout the entire project, nothing speaks against using your own naming convention.