understand naming conventions of interface

Question

I want to understand what uncle Bob writes in the Clean Code book about the naming of interfaces:

These are sometimes a special case for encodings. For example, say you are building an ABSTRACT FACTORY for the creation of shapes. This factory will be an interface and will be implemented by a concrete class. 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. 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. 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.

What is his idea of not starting the interface with an "I", and why doesn't he want users to know that he's handling them an interface?

Answer 1

The validity of this is certainly up for debate, but (as usual) I agree with Uncle Bob on this.

There should be no need for the client of an interface to know he's been given an interface rather than a concrete class, and the client code should most commonly use the interface name, so it's best that the interface name cleanly conveys the business meaning. If it's necessary to encode one or the other it's best not to encode the one you want and expect people to use.

The "I" prefix gives no useful information, and ties you to keeping it as an interface rather than an abstract parent class in languages that distinguish the two.

Answer 2

He says in the quote. It is a distraction, cluttering up the code with unnecessary "I" everywhere when you should be having clear easy to read code, and it also is giving the users too much information that they don't care about.