Interface naming convention [closed]

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.