Tautology and the Programmer
Originally published .
I’ve decided to extract and simplify an example of why a programmer should know what a tautology is… I found very nearly exactly this code in production a few years ago:
if(!a && !b) {
if( ! (a || b) ) {
// stuff
}
}
// ... more unrelated stuff
The if inside another if creates an implicit and … further obviated by the fact that there is no else to the inner if statement.
But, what’s worse the inner if is automatically true if the outer if is also true. The nested if statements form a tautology! The result is that a maintenance programmer must read and comprehend that he is looking at a tautology and understand how to edit the code.
What is particularly bad is if the maintenance programmer doesn’t understand that there is a tautology in the nested if statements and is tempted to put an else after the inner if. That nested else will never fire… and the programmer may waste hours or days trying to figure out why.