Computers are very powerful, but currently still quite dumb - unless we make them smart.

Everyday they are able to do jobs faster and faster. 

That's cool, but sadly for them to be able to do the jobs in the first place, we must provide 

 of the information necessary to get the job done, otherwise they get confused and things break. Guess not that smart just yet.

Either way here's the important part - since in many ways we still are a bit smarter, we can take care of them by letting them know what they should do if something they can't find something they need to get a job done. 

Just like you would to another person you can tel a computer "Hey if data is missing do this instead, else keep doing what you are. So with a simple if/else check we can ensure that a computer doesn't run itself into a wall, if he runs out of road.

Here's an example. Let's say we'd like to calculate a total due after we apply a discount on the price of a pistachio-caramel ice cream.

const calculateTotal = () => iceCreamPrice - discount;

If our discount, for example, is not defined, we will get a broken result (in this case 

const calculateTotal = () => iceCreamPrice - undefinedDiscount;

 discount will leave us with a broken value, anything that would require a number in the following steps would not be possible. For example, calculating the total amount we have to pay - and that is even though the other price will be a valid number), like so:

const calculateTotal = toppingPrice + brokenIceCreamPrice;

This will break the functionality and lead to errors.

To prevent the app from breaking in situations where value is broken, we use a Guard Clause.

With the Guard Clause, we will simply check if the discount is present (we could also check if it is a number, but for the sake of simplicity we will skip that step) and if so, apply the discount. 

Because we only have one more item, we will simply return the price of the ice cream if there's no discount.

const calculateTotal = () => !discount ? iceCreamPrice : iceCreamPrice - discount;

In the above example, we used ternary operator 

 (read this article for more on ternary operators).

Because we added the Guard Clause, which in this case was the first part of the ternary operator we now have a valid total even though our discount is undefined.

An expanded (not ternary operator) version of the Guard Clause would like this:

Why are Guard Clauses better than regular if/else blocks?

The above snippet written with a regular 

 block to do the same checks would like like this:

Because we only have one simple check (whether the discount is present), it doesn't get 

worse, but, it does add a couple of extra lines for the same logic. Additionally, it makes it less readable. So if you have multiple checks that you need to do you will quickly find yourself in nested 

 checks which will make you want to go do your dishes instead of doing programming.

With a Guard Clause, you can terminate your function early if some of the required conditions are not met or if required data is missing. This makes your app more performant, consumes fewer resources, and avoids potential errors.

Questions, comments, better examples? Leave them in the comments below or tweet @ijsto or @scottagirs 🙌

Guard Clauses are very important not only to eliminate errors, but also to improve DX and code readability.