Thursday, November 09, 2006

The "I" Thing

Java naming convention is something developers like to talk and argue about ;) Why it is so important? Let's have a look at the following example. Should we use "I"-for-interface convention? The answer is not easy. One can say (I'm among those) that this makes code more readable because you always know whether you are looking at interface or not. It not so important when you have javadoc and IDE (like Eclipse) because you can just press F3 or any other significant shortcut ;) and you see whether it is interface, class, abstract class, enum or whatever else. The readability issue is more confusing when you have to browse repository using web browser. It is really annoying when you enter the class and it turns out to be an interface without content (I mean implementation).

On the other hand it shouldn't be the case whether you use interface or the class - in fact in ideal world you should use only interfaces (it's not my thought but I think I can borrow it :). Unfortunately ideal world is only our imagination and it is not so beautiful. I agree that all developers (in OOP) should program to interfaces. For us as users of any API the implementation is not important (it's interchangeable) and we shouldn't worry whether we use interfaces or classes.
But there is one thing more which gives "I" prefix advantage over non-"I" convention. If you are a good developer you know that you should use interface and if you see the whole package you can easily choose interfaces and code it. If there is no "I" prefix at the beginning how should you know which class you have to use? Of course it is feasible in reasonable time but it is confusing that first of all you have to dig into the package details in order to find out what is an interface and how should you obtain the implementing object.

Some people say that if we decide to use "I" prefix for interfaces we should use the same notation for abstract classes ("A"), enums ("E"), etc. I don't agree - the only instance that does not have any implementation details is interface. Either enums and abstract classes are implemented (if abstract class consist of only abstract methods and attributes it should be an interface). If enums and abstract classes have any contents developers are likely to view them - unlike the interfaces which are not interesting in such context :) BTW: I know that it is rather against Sun's convention but I try to add "Abstract" prefix for abstract classes and "Enum" postfix for enums - note that every exception has "Exception" postfix - but this is ordinary Java class, isn't it?. For me browsing packages is more convenient with such notation. Of course neither of notation mentioned by me is more helpful that puritan Sun's one if we use javadoc. All types are enumerated in categories: interfaces, classes, enums and exceptions.

Developers can argue (and they do so :) their whole life whether one notation is better that another. What force us to use one of those is our custom. The good thing about developers is that they sometimes can change their habits and they accept changes (sometimes they get back to their old customs when they change their job or department ;). What I wanted to write is that I prefer "I" as an interface prefix, "Abstract" prefix for abstract classes, "Enum" postfix for enums and "Exception" postfix for exceptions - I specifically like the last one :D

If you want to know more about different coding notations and conventions please visit links below:
Java Coding Conventions
Java Code Conventions (PDF)
Eclipse Platform Naming Conventions
Java Coding Standard (Doug Lea)
Chimu Inc Coding Standards
Scott Ambler's Coding Conventions
Naming Conventions in C++ and Java

No comments: