Javadoc implications
Tuesday, August 28th, 2007hanks to everyone who sent in their own examples of pain and horror of bad code. As the saying goes, when you laugh, the world laughs with you. When you cry, inflict your pain on the world so it cries with you. Inspired by all that bad code, I feel that not enough attention is being paid to that other evil-that-can-barely-be-named, bad javadocs.
Every time I see javadocs unmodified from their generated-by-an-IDE form, I feel like grabbing a blunt object and repeatedly stabbing the author in the face until there is nothing left but a bloody pulp. There are few things as offensive as 5-6 lines of absolutely NO new information.
For example, people who like to have such gems as @param myvar. What on earth does that tell us? That the method takes in a parameter named ‘myvar’? Isn’t that blatantly obvious from the method signature? How does this merit all this extra wasted space? Alongside this horror, there is the despicable @return aString taunting us with its unhelpfulness. The same applies to throws docs listing just the name of the exception.
If you want to provide javadocs, great. Anyone using your API will be thrilled and will think good happy thoughts about you. However, I cannot stress enough how satanic it is to provide the illusion of javadocs by having nothing there but skeleton javadocs that suck up valuable precious vertical space. Vertical space in this world, a world horribly skewed in favour of rectangular monitors, is a rare commodity. Lets not squander it so casually.
Another sin regularly committed (although admittedly, one that isn’t as horrific) is ignorance of line breaks and how the standard javadoc doclet handles them. Where you put your full stop (or period, if you’re American) is relevant and important. It isn’t something subject to whimsy or time of the month, there’s a logical approach to it that isn’t horribly complicated. The first sentence gives a brief idea of what you’re talking about. If you have more to say, it goes in the next line and starts off with a new sentence. Think carefully about the first sentence, you don’t want to be like POI, which has the description for the org.apache.poi.hssf.dev package saying a succinct (and wonderfully unhelpful) ‘DEV package serves two purposes’ in the top level index, now do you?