Short #1 Don’t stick to ‘no negations in conditions’ rule

I mean, what’s the point? Let the code flow naturally after the ‘if’ and leave more unlikely situations for ‘else’ (displaying error for instance). In the ‘if’ block, you can put cases that are more natural for your game. A player wants to deal damage to living enemies. It is more common, as dead bodies are usually waiting for being cleaned up and are less attractive for the player. So:

If (!enemy.IsDead())
    enemy.AddForce(FORWARD); // Profane the corpse

It increases readability and stresses the expected game flow. If an attacker tells Mr. Wayne “Give me that wallet, or else…,” Mr. Wayne should give the wallet back, move on and doesn’t care about “else.” It’s the standard course of the situation and that solution should be considered first.

Share these goodies:

Leave a Reply

2 Comments on "Short #1 Don’t stick to ‘no negations in conditions’ rule"

newest oldest most voted
Notify of
Yanick Bourbeau

Common dude, just wrote a IsAlive() function 🙂 The problem with negation in the first IF is that coders often misses the “!”. If you really like to do still use this approach, at least wrote == false in the end. the false keyword get highlighted by most of the IDEs.


Agree, the above example could be rewritten to use IsAlive() function (or property), it sounds better in that case. Pretty common habit though is to have ‘HasErrors’ flag in SDKs. It sounds better than ‘IsFreeFromBugs’ and often we don’t have a choice. In that case we should check if (!request.HasErrors) or if (request.HasErrors == false) as you suggested. Both ways are fine in my opinion if they are standardized for the whole project.