This is no joke.  A bloke on our team came up to me today and asked me about a simple change to some code that was evaluating the BigDecimal.compareTo() operation. (See my earlier blog on why you should do this.) The current code was written defensively to avoid NPE’s:

if (blee != null){

if (blah != null && blee.compareTo(blah) != 0){ return true; } else { return false;}

}

Turns out that the blah != null term was causing an issue as the line would always return false if blah was null instead of the correct answer, which is true. 

So matey wants to avoid the blah != null test failure.  You and I would simply break up the if..statement into two if..statements comme ca:

…

if (blah == null ) return true;  // assuming that blee above was not null

if (blee.compareTo(blah) != 0) …

Much to my dismay, this colleague wanted to NOT do this, but instead add an additional line setting the blah to some random BigDecimal value because “I will chose a number that will never be used”.  

…

if (blah == null) blah = new BigDecimal(-7878); // WTF?!!?!

if (blah != null && blee.compareTo(blah) != 0){ return true; } else { return false;}

What? Eh?  Can he really guarantee that claim? I see our future, and it involves many hours digging out this hard-of-thinking code.

Don’t worry, I straightened him out.