Question

I remember many years back, when I was in school, one of my computer science teachers taught us that it was better to check for ‘trueness’ or ‘equality’ of a condition and not the negative stuff like ‘inequality’.

Let me elaborate – If a piece of conditional code can be written by checking whether an expression is true or false, we should check the ‘trueness’.

Example: Finding out whether a number is odd – it can be done in two ways:

if ( num % 2 != 0 )
{
  // Number is odd
}

or

if ( num % 2 == 1 )
{
  // Number is odd
}

(Please refer to the marked answer for a better example.)

When I was beginning to code, I knew that num % 2 == 0 implies the number is even, so I just put a ! there to check if it is odd. But he was like ‘Don’t check NOT conditions. Have the practice of checking the ‘trueness’ or ‘equality’ of conditions whenever possible.’ And he recommended that I use the second piece of code.

I am not for or against either but I just wanted to know – what difference does it make? Please don’t reply ‘Technically the output will be the same’ – we ALL know that. Is it a general programming practice or is it his own programming practice that he is preaching to others?

NOTE: I used C#/C++ style syntax for no reason. My question is equally applicable when using the IsNot, <> operators in VB etc. So readability of the ‘!’ operator is just one of the issues. Not THE issue.

Answer 1

The problem occurs when, later in the project, more conditions are added – one of the projects I’m currently working on has steadily collected conditions over time (and then some of those conditions were moved into struts tags, then some to JSTL…) – one negative isn’t hard to read, but 5+ is a nightmare, especially when someone decides to reorganize and negate the whole thing. Maybe on a new project, you’ll write:

if (authorityLvl!=Admin){
 doA();
}else{
 doB();
}

Check back in a month, and it’s become this:

if (!(authorityLvl!=Admin && authorityLvl!=Manager)){
 doB();
}else{
 doA();
}

Still pretty simple, but it takes another second.
Now give it another 5 to 10 years to rot.
(x%2!=0) certainly isn’t a problem, but perhaps the best way to avoid the above scenario is to teach students not to use negative conditions as a general rule, in the hopes that they’ll use some judgement before they do – because just saying that it could become a maintenance problem probably won’t be enough motivation.

As an addendum, a better way to write the code would be:

userHasAuthority = (authorityLvl==Admin);
if (userHasAuthority){
 doB();
else{
 doA();
}

Now future coders are more likely to just add “|| authorityLvl==Manager”, userHasAuthority is easier to move into a method, and even if the conditional is reorganized, it will only have one negative. Moreover, no one will add a security hole to the application by making a mistake while applying De Morgan’s Law.