Do you Encode your interface ?

Yesterday , i was reading Clean Code by Uncle Bob. While i was doing so , i came across a line that really stuck my thought patterns and i would like to share it with my readers as well.

The line looks something like, provided that there is a shape factory that will be implemented by concrete classes.

“What should you name them? IShapeFactory and
ShapeFactory? I prefer to leave interfaces unadorned. The preceding I, so common in
today’s legacy wads, is a distraction at best and too much information at worst

....

So if I must encode either the interface or the implementation, I choose
the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable
to encoding the interface.”

 

This is true, in a sense today even our popular refactoring tools [there are not much, so you can easily figure out] when typed, precedes the interface with “I” word. And if we look though all the open source foundries, we will  see this here and there with no exception. Even honestly, i encode interfaces with “I” word, but technically it would be much better if we have a structure like

Shapes.Abstractions

| ShapeFactory

CSharpShapeFactory

 

After, reading that i came to realization that we should abandon this “I” encoding for interfaces that is going on decades to devs after devs. There should be a  “General coding guidelines” which should include it and FxCorp should mark it as invalid during code analysis.

Now, did i say something wrong , enlighten me, why we still need to encode our inferface, when our modern compiler are smarter enough to do it for us. I guess we are way too ahead from the days of integer based type encodings , aren't we ?

 

[Edit : This is true that  starting an interface with “I” has become more of a convention today. [SA1302: InterfaceNamesMustBeginWithI]. There are numerous project that follows it even i don't remember, i wrote one without it, at the same time the words at the book still worth thinking along with meaningful names as stated [From book] “I don’t want my users knowing that I’m handing them an interface. I just want them to know that it’s a ShapeFactory.”  Also, there are comments like, “I like “I”  because i want to know that its an interface, but question remains what productivity it will really provide?. Finally, convention is important to make us feel right at  home  but its not bad to discuss on other options that are forwarded by an industry expert, i mean there must be a reason.]

[Edit: The title should rather be why you should use “I” in your interface just because it’s a convention or you are used to it, what if you don’t use it , is there other options and are they worthy ? ]

Shout it

18 Comments

  • Yes I do
    If I just want to check if some instance implements an interface I call (myClass is IMyInterface).
    So without knowing the type (is it a class or an interface) I just know it by reading the statement

  • I think you're wrong mate. I want to be able to see from a name that it is an interface when going over some code, and I does that for me. The compiler doesn't do that for me.

    It is not encoding BTW, it is prefixing... ;-)

  • Hi Christen,
    It is encoding, prefix generally used by you like m_myvarible to identifiy module level with local item or any speficific reason. But "I" is a econding, where it is used to mark the inteferface. we are adorning the type with something to make it look like something.
    And it is useless to mark it with "I" rather grouping it in differnt folders. I would deeply appriciate if you go to through chapter 2 of Clean Code.

  • Completely Disagree.

    Its widely accepted, and most importantly easier to find them.

    why change something that works?

  • Hi,
    Its not an issue to argree/disagree about , rather a question why should we prefer to use "I"  [Even me].
    Its fine that it provides a marker to interface, but what we really do with it. If we put that in abstraction namespace wont that make more sense ?
    I am no expert on naming but reading the lines that what made me to rethink.

  • Having it in an abstraction namespace doesn't help you identify that it is an interface. For variables, properties etc.. you don't need prefixes because you can easily identify them by their naming conventions. Eg:

    1. myField
    2. MyField
    1 is a field/variable, 2 is a property. But for interfaces you would get:
    1. MyClass
    2. MyClass

    Hmm, so which is the interface? They aren't prefixed with the namespace so I got no clue that #1 is actually is Abstraction.MyClass, therefor you want to prefix it with "I".

    Code should always be readable without having to use intellisense in my opinion (Hence I'm not a big fan of dynamic/var).

  • I have read Clean Code and this is one of the few things in the book that I disagree with. C# and Java use the same syntax for inheriting from a base class and implementing an interface.

    public class MyClass : MyBaseClass {}
    public class MyClass : IMyInterface {}

    Using the "I" prefix makes it clear what you are doing. VB.NET has different syntax for inheritance and implementation so it is probably not a big deal there.

    In any event, it has become a convention and I think it makes the code clearer.

  • There are some very good guidelines, including on naming conventions in "Framework Gesign Guidelines" [2nd ed. Cwalina and Abrams]. The use of I as a prefix for an interface is widely used, accepted and clearly separates an interface from a base class. Using a separate namespace for the abstractions may not always be a good idea as it will force the users of the library to add at least 2 using statements. Commonly used stuff should be in a common namespace, while advanced scenarios should hide advanced functionality in nested namespaces. Of course, the latter recommendation depends on the situation.

    One thing mentioned in Cwalina's book, and I agree, is that blindly using interfaces everywhere is not correct engineering, although it may seem so. Using an interface seals the public contract and freezes extensibility, while enabling alternate implementations. For example, adding a single method to an interface will need changing every single implementation of the interface. An abstract base class can provide nearly the same level of abstraction, while enabling future extensibility without breaking code. The .Net team made Stream an abstract base class and not an interface in .net 1.0. Later in 2.0, they could easily add streams supporting timeouts, without having to change any client code existing worlwide.

  • Yes, I do, following StyleCop rule SA1302.

    But I also have Visual Studio set to show interface type names in a different colour to other types (Tools > Options > Environment > Fonts and Colors > User Types (Interfaces) ), so if I need to make a query like (myObject is MyInterface), the I could see the interface nature by colour, even without the sigil.

  • hola!,
    i agree with richard, since camel casing is widely accepted in C#. so you can't directly move into a different convention. prefixing or suffixing is required in such case.

    if CC wasn't widely used in C# you guys could follow what bob prescribed, more over these days IDE are very intelligent, they shows different icon for abstract class, concrete class and interface so it won't have any problem to differentiate.

    btw, if you are using a different namespace for keeping all interfaces that would become a different new convention. interfaces are the public front those are used for hiding all concrete implement class.

    since you guys are using IoC container these days, you don't exactly need to know the concrete implementation class of any specific service.

    anyway nice thought!
    best wishes,

  • I disagree. I consider the 'I' in interface-naming a tradition and traditions are what help make a profession mature (Software Engineering badly needs maturity). Doctors prior to surgery wash their hands 10 times when 3 suffice, psychologist always have their patients seat in a certain way, on a certain chair and have a questioning-format and other examples from other fields. Keeping the 'I' in interface-naming is totally unncessarily programining-wise but is excellent for the field. It is a nice step towards traditions- helping keep things consistent and providing markers that helps everyone know what they ought to know to understand code.

  • @all thanks for all the valuable comments, much appreciated.

  • There really should only be 1 answer to this.
    1. It depends on the framework/language you are using.
    In .Net, MS decided to prefix interfaces with an I, so that means, when we write with .Net we prefix with an I. It makes the code look cleaner when intermingled with the .Net framework
    With Java, Sun didn't prefix, so we don't when we're in Java.
    Really, it's that simple. Just like you don't enter a new codebase and start writing your own style (you conform to the existing standard), so you should also do that with your language, and whatever framework it supplies

  • @Colin
    You are right!!

  • I encode my interface with a capital "I". This helps me to look at code and understand and think better. The "I" prefix is for humans not compilers. It lets you understand a bunch of source code without having to look up the in the file if that is an interface or a class.

  • I don’t find Mehfuz (the Author) insist not to prefix interface with I, instead he raises a valid point to make us think twice.

    And I don’t buy having an I before the interface makes the code more readable, and the people who are claiming this, I bet they are not using prefixes like str, int, dbl, in their variable names, I think those vb6 days are long gone.

  • Using str, cls, bdl etc was Hungarian notation which is still recommended by many for c++. Microsoft recommends using an I for interfaces (and it condemns any other prefixes) for managed code. It's a convention in .Net put forth in the Framework Design Guidelines.

  • @Heartattak
    All things you said is valid and we know it but let's say you are exposing an API to the client, where the client can extend it if he wants to , here as uncle bob said we dont need to let the client know if its an interface or abstract or class with some virtuals.

    @All
    This is more of a controversial thing, there is no necessity that we need to do it by book or what uncle bob said, but we can always put discusstions to justify something. I think , its now well justfied why we should use "I" [From all your inputs] and thanks !!!.

Comments have been disabled for this content.