Coding Conventions - _I_ want to kill the Impl
This is actually a fun debate... I'll wade in:
First, Cedric pontificated recently about using Hungarian notation in Java. You know, stuff like "lpszStringName"... You can just guess my thoughts: Oh. God. No. And this isn't just because it's a Microsoft thing, it's because it's damn ugly. And it doesn't even make sense in Java... I think lpsz means something like "long pointer zero terminated string". How does that even relate to a String object in Java? That's generally what's wrong with Hungarian notation, it just doesn't fit most of the time (though I've seen people try).
At the bottom of the post, Cedric also mentions the use of "m_" in front of member variables in your class (which isn't part of Hungarian notation, but common nonetheless). I just want to say that I'm against all uses of the underscore _ in any form in programming. It's one of the things that bugs the f*ck out of me about Python. You want to throw an "m" in front of your local variables, you go right ahead, but leave the _ at home. Even worse is names starting or ending with _. AAAGHHH! "_name" is NOT a clear way to program!!! I just want to strangle people who write code like that. That's the problem with most programming languages - they allow too much. We don't have WORDS that start with _, why the hell would you want a variable to start with it? But, as always, I digress...
Cedric then continues today (yesterday?) with some thoughts about interfaces - specifically using an I in front of interface names to differentiate between them and classes (e.g. "IWorkspace"). And THIS is where it gets interesting because Charles thinks that that's about the most evil thing he's heard in a while. Yeah! Let the beetle battle begin! (Sorry, too much Dr. Seuss lately...)
I need to say that first, both Cedric and Charles made comments like "the IDE will save us" in their posts and IMHO they're both wacky on this point. Languages and any notations you decide to use need to be able to stand on their own. If you're doing something that needs an IDE to figure out, then you're in trouble. Whatever convention you use has to be inately understandable by any programmer walking into your code even using VI.
Secondly, I think that Cedric may have a point on this one. Let me tell you why: The main reason is I detest, loathe, hate, and want to vomit on any class that ends with the letters "Impl". UUUUGH! IBM stuff is super-famous for this. Almost everything that comes out of there has this convention going. It's like someone at IBM skipped a chapter or two in the OO book and decided that classes were less important than interfaces, so the interfaces get all the readable names and the classes get a Impl stamped on their ass. It must have something to do with the IBM mentality. I don't know. What I do know, however, is that classes are the principle objects in Java, not interfaces. Interfaces are handy, dandy and cool, but they're there to help structure your classes and allow interoperation without multiple inheritance, NOT to be the prime way of programming. If you're thinking "I'll just program to interfaces and forget about those classes", you need to come up to speed because I think that fad went out a couple years ago.
So the only real alternative to labeling the classes is to label the interfaces and "I" seems alright to me. But I can see Charles point about being a bit awkward to use... I mean, I really like being able to use "Collection col = ..." and not "ICollection col = ...". But I think it's a common enough problem that there needs to be some sort of convention for it. It's too bad "interface" is too long a word to tack on to the end of your interfaces ("CollectionInterface c = ...") Ugh.