Swift 2.0: Why Guard is Better than If

Swift 2.0 comes with the excitement of the guard statement. But looks like there’s still confusion as to why guard is AMAZING, especially compared to the simple if statement before Swift 2.0.

That is a completely reasonable question. So why is guard better than just a plane if? Let me count the ways…

The Setup

I’ll use the same example as in my Error Handling blog post – a simple form with a name and age field – so please take a look at it before proceeding.

The part I’ll be focusing on is the viewModel, specifically the createPerson() function:

Here are the benefits of using the new guard paradigm in the createPerson() function:

Pyramid of Doom

I’ll start with the most obvious – the infamous Swift Pyramid of Doom. Here is what the createPerson() function would look like using the if statement:

Sure, the Pyramid of Doom get a little better with the Swift 1.2 unwrapping of multiple optionals on the same line, but you got to admit this is not pretty and hard to decipher the meat of this function (actually creating the Person!) at first glance.

Compare this to the above implementation with guard – it’s so much more readable with the Person being returned at the very end, making it clear that that’s the main goal of this function all along.

Return Options

Notice that when using the if statement version of the createPerson() function (without the guard), we have very limited options on the return value.

In my case, I’m returning an optional Person – the person either exists or not. This puts an additional Pyramid of Doom responsibility on the caller of this function:

But what if you want to be more specific – if there’s an error, you want to return what the exact error is to show to the user filling out the form. Well, in this case, you would do something like this:

This Haskell-like Result Enum solution is not bad, except for the fact that you’re now returning a PersonResult instead of a Person like you meant to and you can ignore the failure option if you wanted to.

With the new guard syntax, the return value is what it’s meant to be – in this case you’re meaning to return a Person object, and the compiler forces you to handle the error cases when the Person is not returned as expected:

Screen Shot 2015-07-16 at 5.47.01 AM

So the caller’s result catching syntax with guard looks like this:

Happy-Path Programming

Finally, the most elegant thing about using guard vs other programming paradigms (like the nested if statements) is that you’re coding for the happy path while still being forced to handle early exits caused by possible errors. It reminds me a lot of the famous Railway Oriented Programming talk.

Recipe_Railway_Transparent

You’re coding for the green, with early exits if things go red at any point. It’s a very elegant way of approaching code without the overwhelmingly complicated functional syntax described in the talk. Reading the code, you can immediately see what the happy path is:

I’m sure I’m missing some other points on what makes guard so awesome, so feel free to contribute in the comments!

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.