if(condition == true) {
return true;
}
else {
return false;
}
Everyone should recognize this by the time they've completed a CS (or equivalent) degree. There are two things wrong with the above code. First, if the condition variable is boolean, then there's no need to compare it to true. Second, the whole idiom simplifies down to just
return condition;
There, we've just saved five lines. I've corrected this so many times I've lost count. Then what's my point, you ask? When is the six line version really okay? When you're debugging. Sometimes you want to set a break point where the condition is either true or false. If you only have the return statement to set the break point on, the debugger stops every time it hits that one line. That's really annoying if the condition you're interested in only happens once in a thousand evaluations.
So what's the real lesson here? Even when you know you're right, even when you've been right for years, you can still be wrong.
4 comments:
Any reason not to set the breakpoint on the return line but make it conditional? That's certainly what I'd do in Eclipse - which IDE do you use?
Conditional breakpoints are heavier than unconditional ones in terms of performance, but I'd rather that than morph my code out of shape :)
And you are definitely STILL WRONG! Conditional breakpoints are what you need... I totally agree with Jon.
You're both right, conditional breakpoints are better in this case if you have them. I don't worry about them being "heavier" because it doesn't matter how slow your code runs in the debugger.
By the way Jon, I use NetBeans, so I definitely should be using conditional breakpoints. Also, I love your blog.
locivars, am I "STILL WRONG", or was I right all along? :)
Post a Comment