Most of time one (should) works with interfaces, so it makes sense to have a simple name that describes the “what” and not the “how”. A prefix like “I” is just ugly, and becomes silly as good code will have a lot of interfaces. Using a compound naming system like implementation detail + interface name is descriptive. ArrayList and LinkList are perfect examples of this, each describing “what” type of “List’ they are.

This red herring quacks like a straw man! I don’t see Eric saying must use *Impl, must not use I*.

“In short, your position is ‘I don’t care about differentiating interfaces from implementations when reading code’. Matter of taste I guess, but I do code reviews several times a day and a consistent convention is a life saver.

I’m guessing you don’t often review code that is not yours?
“”"

This is not a good enough reason to introduce noise anymore. I spend most time reading other people’s code these days and the answer was simple – highlight interfaces in your Java IDE settings. You’ll see concrete class easily, especially where they’re being new’d or passed in as arguments. If you’re reviewing patches, then apply them so they show up instead of just eyeballing changesets.

I guess the meta argument that interfaces are hobbled compared to constructs like Scala traits is for another day

Consider a Lamp class with switchOn() and switchOff() methods. When you extract an interface, should you call it “ILamp” ? No, you should call it “Switchable” !

On the other hand, Eric I wonder if your notes about Hungarian notation might just be stylistic preference. I’ve used it a lot in the c/c++ world and it’s a really useful convention, only partially obviated by modern IDEs.

I do something similar when naming members. In .NET or java I wouldn’t even consider using underscores. In python I follow the PEP-8 convention which uses underscores all over the place. Again, follow the framework’s lead.