views:

1312

answers:

13

Does anyone know the rationale behind this naming convention? I don't see any benefit. The extra prefix just pollutes the API.

I like Konrad Rudolph's response found in this related article

+2  A: 

It makes it easily identifiable as an interface.

scottm
I don't see any direct value in distinguishing between interfaces and implementations. Further elaboration might help.
i3ensays
To me, at lease, Implementation means a class, which should be defined according to logical entity/ object semantics, whereas Interface means behavior, or contract, which should be organized according to logical groupings of connected behaviors.
Charles Bretana
+2  A: 

It's either that or add "Impl" to the implementation of the interface (argh). I don't have a problem with the "I", it is the simplest and most straightforward naming for an interface.

Otávio Décio
I disagree with the "Impl" suggestion - it would be wasted noise just as the "I" prefix is. An implementation should be named with its implementation in mind. For example, an interface "Database" might be implemented with "RelationalDatabase" and "InMemoryDatabase".
i3ensays
It's a convention, you are not required to follow it if you don't like it.
Otávio Décio
Not a matter of me liking it. I'm questioning its value. I like to adhere to conventions not solely for the sake of following the pack. I want to understand the rational. Hopefully, someone can articulate that rational beyond "it lets you know its an interface" (which the IDE does w/ pretty icons).
i3ensays
A: 

Most likely its to make it easily identifiable in intellisense, since all the interfaces will clump together. Similar to how I prefix all my UI controls with btn, tb, lb. When intellisense kicks in everything is clumped together in one easy group.

Kwan Cheng
I believe the IDE can "clump" without use of naming conventions.
i3ensays
+13  A: 

I also like it cause I can read it as "I verb-behavior" as in "ICanSave" or "IDoDoubleEntry" etc...

Charles Bretana
Most meaningful answer I've read yet.
i3ensays
IEnumerable - sounds like a caveman talking. Ugg.
mackenir
Perhaps the prefix should be 'Me'.
mackenir
yeah it could be argued that the "Am" is implied.. "IAmEnumerable" would arguably be clearer, albiet longer.
Charles Bretana
Haha, definite upvote for IDoDoubleEntry.
macke
+1  A: 

Naming conventions offer the benefit of telling you something about the object before you use it. Naming conventions have been widely used for many years, going all the way back to fortran's insistence that integer values were restricted (if I remember correctly) to variable names like "i" and "j".

Hungariation notation took naming conventions to a whole new ugly level tha described the variable type, whether or not it was a pointer, etc. Many of us who were exposed to lots of code with Hungarian notation developed nervous twitches and verbal stutters.

Prefixing interface names with I is a relatively low-impact, harmless way of identifying that object.

Kluge
How does identifying a type is an interface benefit the API? (I do understand the difference between interfaces and classes).
i3ensays
+29  A: 

Its the complete opposite, the naming convention clearly shows what is an interface.

For example if you have:

public class Dog : IPet, IMammal { ....

Just from reading it, I can clearly see that IPet and IMammal are probably interfaces.

The .NET CLR allows for single class inheritance. So, if I have a base class..I can only inherit one class from it. Lets change the IPet interface to a base class..our example now bebomes

public class Dog : Pet, IMammal { ....

I am inheriting from the Pet class and implementing the IMammal interface.

If we did it what you are suggesting and removed the letter "I" we have this:

public class Dog : Pet, Mammal { ....

Which one is the class I am inheriting from? Which is the interface I am implementing? It gets confusing right? (FYI..you are supposed to put the base class always first, so you could argue that point...but it you are arguing to remove the letter I from interface names I doubt you follow that practice as well)

As you can see that naming convention easily tells me a lot about my object without me having to investigate further. I can easily see what I am inheriting vs what I am implementing.

A

Bart Czernicki
It makes sense. So, in C# , Java's "extends and implements" are mixed together?
OscarRyz
I follow the "base class always first" convention you mention. Nonetheless, I can't agree with your claim "naming convention easily tells me a lot about my object". Case in point, distinguishing between interface, abstract/concrete class, enum, struts, etc. isn't meaningful to me at the API level.
i3ensays
Why don't we prefix abstract/concrete types with "A"/"C", enumerations with "E", structures with "S", etc.?
i3ensays
I use a programming "environment" that is SO awful, that methods, attributes, and objects, must be prefixed with "met, attr and obj" repectively. objEmployee.metUpdate( objOther.attrId ). This is extremely readable and very clear, but I just hate it!!!
OscarRyz
@Oscar - I can't tell if you're being sarcastic or idiotic. Either way I don't think any sane programmer would vote for those uses.
i3ensays
it doesn't sound like it's his choice
jbu
This is the best answer, but the actual reasons are (according to Krzysztof Cwalina) that "I" is used for `historical reasons` and (according to Brad Abrams) that it is a `clear recognition of the influence of COM (and Java) on the .NET Framework` and the decision to carry it forward was because so many early adopters of the .NET Framework `were already familiar with COM`. (See this answer for the more detailed quotes. http://stackoverflow.com/questions/222457/are-there-established-alternatives-to-isomething-isomethingable-for-interfaces/222500#222500)
Scott Dorman
I personally like that all interfaces are prefixed with an 'I'. It allows me to immediately recognize an interface quickly.
galford13x
It is rather ironic, that java actually got it right. No longer are the interfaces prefixed with an "I", but it is actually considered BAD practice. See "Effective Java" by Joshua Bloch.
drozzy
+9  A: 

Actually I find it useful to avoid naming clashes, I might for example create a concrete class called Fred that implements IFred

Tim Jarvis
+10  A: 

I think that the IInterface naming convention is silly. It's an example of Hungarian notation, and I subscribe to the school of thought that despises Hungarian notation. If you have an interface with only one implementation that has the same name, consider the possibility that this is a code smell.

However, I still use it, because in this case IInterface is recommended by Microsoft, and "standard is better than better".

Sean Reilly
I was never a fan of hungarian either, but I came across this old Joel article recently, which explains its origin and how it has been widely misunderstood - at least I can see the reason behind it now!http://www.joelonsoftware.com/articles/Wrong.html
Mathias
+3  A: 

I always thought it was fun to use verbs for behavioral interfaces. This is a departure from the class naming convention of using nowns, but it allows the class to "speak" to its behavior.

class Dog: IBark

This does not work well for structural interfaces like WCF interfaces, but we don't need to have fun all the time.

to answer your question, think of the I as "implements" So...

class DogDataService : Dog, IDataService

this service class inherits from Dog and implements IDataService

I'm still not really answering your question, but the I is useful because you get naming collisions between namespace, class and interface.

namespace DataService
interface DataService
class DataService: DataService

so we end up with

namespace DataServices
interface IDataService
class DataService : IDataService

I think in reality, it's a sanity convention.

Mark Davis
+1 - generally speaking I think naming conventions indicate a weakness in the development language (and that is probably the case here), but it is nonetheless important to be able to avoid those collisions when you want to use dependency injection and to mock collaborator objects. There's really no alternative to a naming convention when you're creating interfaces for domain objects.
Jeff Sternal
/shrug I use it for WCF services too. I have IServeData and ICanMakePayments for my two services.
Kyle Hodgson
A: 

It is just a naming convention so everybody would know if it is an interface or something else it is not mandatory nor by the compiler nor by the IDE but All the interfaces i saw in my entire life starts with the letter I

Yassir
A: 

Firstly I believe prefixing with I then description is wrong because it means implenentations can have a shorter name. IList (intf) -> List. This is an antopattern as we all know we should beusing intf and probably only concrete types when creating. Don't flame me this is a generalisation but the premise is intf only impl rarely. The implementation name should describe how it's implementing the intf or what it's doing. Think intf List, LinkedList which implements List using a linked list. Who cares if it's longer as we should be using List most of the time. If we have a class implementing many intf we probably should not include all the intf as the shadows the real purpose of the class. IN the case something removed without the intf makes sense. Eg ppl call me by name not Person, Sibling, developer etc using my name is the best most descriptive name. I suppose if a class is impl a simple intf then call it DefaultIntf which makes it on ious this is the deafulT implementation of Intf. Names of classes sHould in the end be human readable and almost a short phrase describing their purpose. Prefix codes etc are not great as we communicate with words not codes. Computers do t cAre what classes are called so why remains is that we name things so the names help us and our colleagues.

mP
A: 

The "I" convention seems to be an old convention that wouldn't be relevant today. Current code editor provides lots of insight about the type you are using, so arguing that It's easier to identify the interface is like asking for a namespace to be prefixed by a "N" because you want to be sure that you will not confound it with a concrete class (prefix with a "C"?).

A convention doesn't mean that It's a good convention. Sometimes, It's just because people get to use it...

Take for example the C# documentation generator: It doesn't care about it... if your interface is not prefixed with a "I" you will still see your interface in the interface part of your documentation. Do you really think that having a prefix "I" for all your interfaces inside the interface section of your documentation is a relevant information and help you to better identify interfaces?

Alexandre Mutel
A: 

Why isn't this a function of syntactical highlighting instead of Hungarian notation? Why doesn't the IDE just italicize identifiers that refer to interfaces if it's so important to distinguish between classes and interfaces. I hate putting "" or "m" before fields, "C" before classes, etc. Even worse, it encourages programmers write really bad APIs like

public class List : IList

instead of

public class LinkedList : IList public class ArrayList : IList public class HashList : IList

Even the .NET common class authors fell into this trap. A class name should NEVER be the name of the interface with just the "I" removed. The class name should always tell the user how the class differs from other possible implementations of the interface(s). I vote for dropping the stupid "I" for that reason alone.

Also, when I use intelisense, I want to group things by functional area, not whether it's a class or interface. I never think, "I need an interface, not a class." I always think, "I need something that does X".

Dan