Let’s say you’re writing a method or a function that returns a boolean value (true or false). My usual way of writing these things is to write a default return statement at the bottom so the code will compile. So say I’m writing a method called thisWorks(). It will be full of code conditional statements that test whether “this” doesn’t work, each of which returns false if that’s the case. If none of the conditions are true, at the end we get to a bare return true. I think this leads to bugs, and that the safer approach is to always end the method with a conditional statement, not a bare return statement. So your method ends with:
if (lastTestFailed) {
return false;
}
else {
return true;
}
It seems to me that making such a rule prevents you from failing to return something when you should and falling through to the default return value. I’ve been burned by that a few times lately. What this says about using languages that simply return the value of the last expression encountered absent an explicit return statement, I don’t know.
Update: I’ve heard from several people that this is not a comprehensive solution to the problem that I described, which is unfortunately true. It solves one class of problem where you write a new method with a return statement at the end and then add in some conditionals, but if you insert other conditional statements prior to the conditional statement that I bothered to type out above, you can introduce bugs of exactly the type that I’d like to avoid. Perhaps there’s some way to write these methods that avoids these problems, but it looks like once again the safest solution is to write comprehensive unit tests.
Just so you know
The United States is about to advanced fighter planes capable of carrying a nuclear payload to Pakistan. It’s OK, though, because the plan is to sell something even better to India. Sleep well.