It's much easier to write for failure than it is to write the correct logic.
What do I mean by this?
Writing code that looks for the flaws first will be the most optimal way to write code. It creates a flawless system that checks every nook and cranny of your code to ensure it doesn't blow up in your face later down the line.
In a perfect world we would all be writing flawless code. However, I've found that the concept of writing for failure is much easier to do and will also help you reach your end goal of that perfect code.
How does one write for failure?
Logically you start trying to handle every possible error you can think of.
You take logic based statements and try to force them to always return a value as soon as possible.
Written Traditionally:
bool isGameRunning = false;
if (isGameRunning) {
// do some stuff
return true;
}
Most programming tutorials will teach you the above format.
We go inside the code and check if the variable isGameRunning is true. Then if it is we go into the brackets and do some additional stuff.
Instead what we could do is write for failure...
Written for Failure:
bool isGameRunning = false;
if (!isGameRunning) // This code will return false immediately.
return false;
// Do some stuff
return true;
We go into our if statement and check if the game is running. It's not running so let's just kill this branch of code right now.
Why would we ever write code in this manner? Does it not function the exact same way as the example above this?
You are correct in thinking it does function the same way.
The catch here is that it immediately ends the code and doesn't proceed any further.
We are writing code that should be easy to understand, isn't heavily layered, and find the first solution immediately.
You want to be able to write code and then come back and read exactly what it does a week from now.
Let's add some additional if statements to the original code.
Written Traditionally:
if (isGameRunning) {
if (isPlayerMoving) {
if(playerPosition.Distance(entityObject) <= 5) {
return true;
}
}
}
return false;
Start stacking on all these if statements and layer them like we've done above.
Imagine having five or six of those stacked together and you're trying to manage your code.
It's an absolute nightmare.
Take a look below to see how we can handle it if we write for failure instead.
Written for Failure:
// Check if the game is running. If not end it here.
if (!isGameRunning)
return false;
// Check if the player is moving. If not end it here.
if (!isPlayerMoving)
return false;
// Check if the distance between the object and an entity exceeds 5 units.
if (playerPosition.Distance(entityObject) > 5)
return false;
// Else do whatever we need to do here and then return true.
return true;
If you were working on a project and you had to read someone else's code would you rather read layered if else statements or the code that was written for failure?
Not only that we're immediately causing our code to fail as FAST as possible.
Which in turn increases the overall performance of our program.
Would you rather write for failure? or write traditionally?
