Defend thyself!

I have learnt many invaluable lessons from my friend and top notch software engineer Jock Murphy. One of them was to code defensively. If there is the remote possibility that something can be null, be prepared to handle it. Although I have never forgotten that lesson, I fail to implement it many times. The past couple of days have been particularly horrific. I've had NullPointerExceptions laughing their heads off at me. And at those moments, I remember Jock and curse myself.

I also remember the yellow bit of paper on which I wrote down his programming practices as he told them to me and a colleague about a couple of years back.
I still have that paper- and I am sure that he will not mind if I share the contents with you for the good of software-kind.


1. JavaDoc- Public and protected methods and properties should have JavaDoc. Things that you should put down is the purpose (what it does or what it is- not how it does it), inputs, outputs and exceptions. I have noticed that usually, JavaDoc falls into three categories- none, wrong, or excessive. I don't believe in adding JavaDoc for regular getters and setters, unless your getter or setter does more than meets the eye. In that case, one should consider why it does that in the first place. Otherwise, document it.


2. Magic Numbers- You should never, ever have a magic number in your code. For example,
int something=somethingElse * 329;

What the heck is 329? It should be:

int something=somethingElse * Constants.NUMBER_OF_VIEWS;

You could define that constant externally in an interface, or locally in the class if it is the only class that will ever use it. Just imagine if 23 classes use 329- and then someone tells you it should be 330. Instead of abusing the guy and doing a search and replace, just go change the constant.

Imagine if you did do a search and replace and class A had the line:
int foo= bar + 329;

329 here means something completely different. You have then shot yourself in the foot. Define another constant!!


3. Logging- Logging is your friend. Log exceptions, unexpected conditions, logic failures

4. Exception Handling- Sure it's nice to define our own custom exceptions. But define and use them wisely. Don't throw exceptions all over the place- they are expensive. When you encounter an exception, log it and then handle it, or pass it on. If you don't require to have an exception thrown, don't throw one. Usually, many custom exceptions can be handled in other gentle ways.

5. Defensive Programming- As mentioned above, be prepared to handle any bad data. And assume as little as possible.


It's not rocket science- there are no buzz words or impressive rules... just plain basics...but believe me, if you follow these, you will be much happier...

Thank you Jock...I am a better engineer today :-)

-Luanne