Understand Swift 2.0 guard statements in iOS 9
Hi everyone! “guard” is a new keyword introduced to the Swift 2.0 language for iOS 9. Our first thought when looking at the guard statement examples is likely, “um… that’s just an if statement with more characters in the keyword”. In some sense, that’s true, but the guard statement has some subtleties that make it much more attractive than a simple if block. In this tutorial, we’re going to look at the guard statement, what it solves, and why it’s better than the if.
Here’s our problem. Let’s say we have a registration screen that has the user enter their name, email, and a password with confirm. If any of these fail validation when the user presses “Register”, we’ll put up an error dialog stating we failed. Otherwise we’ll submit the data to our server for registration.
We might see code like this. If you do, go smack the developer and tell them to quit it. The reason you might see code like this is the developer is trying to keep all the unwrapped optionals in scope. The unwrapped optional from the if let is only available inside the scope of the if block.
Now if the developer had coded things for an early exit, it might look like this. It’s better but, the problem is we lose the unwrapped optionals when the data is valid. We’re also testing for the values we don’t want. We’d need to unwrap it again. That’s no good either.
Here’s the solution. We’ll still exit early, but we’ll do it with guard statements. The syntax looks like this. It’s really two keywords, because the else is also required.
The first difference is the guard statement’s code block is run only if the condition is not met. We’re saying “assert this is true, otherwise run this code”. It makes the code a bit easier to read, since we’re testing for the condition we want.
The second difference is we can use the optional outside the statement. If we had coded this using if-lets, we need to reverse the condition. We might also start nesting our ifs for each condition to test. We already saw that was bad.
Guards can have multiple unwrapped optionals just like ifs too. You lose granularity on your errors, but it makes the code much more succinct. Your call on that one.
What does the guard statement buy us? Well it does make our code a bit more readable because our intent is clear when we test for the condition we want, and it does allow us to make an early exit readable, but I think the biggest advantage is the guard statement and unwrapped optionals are in the same code scope. It allows us to have readable asserts at the start of our method, and then happy path code following the asserts.
Have you started using the guard statements in your code yet? If so, let me know how it’s going for you in the comments below. On the DeegeU channel there’s over 50 different tutorials as of this video. Swift is a new category, and new Swift videos will come out each week. Make sure you subscribe. That way you don’t miss a tutorial! Thanks for watching, and I’ll see you in the next video!
<!-- DeegeU - Right Side -->
<ins class="adsbygoogle" style="display:inline-block;width:336px;height:280px" data-ad-client="ca-pub-5305511207032009" data-ad-slot="5596823779"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script></p>
Tools Used
- XCode
Media Credits
All media created and owned by DJ Spiess unless listed below.
- No copyright infringement intended.
Get the code
The source code for “How to override a method in Java” can be found on Github. If you have Git installed on your system, you can clone the repository by issuing the following command:
git clone https://github.com/deege/deegeu-ios-swift-guardTests.git
Go to the Support > Getting the Code page for more help.
If you find any errors in the code, feel free to let me know or issue a pull request in Git.
Comments
DJ Spiess
Your personal instructor
My name is DJ Spiess and I’m a developer with a Masters degree in Computer Science working in Colorado, USA. I primarily work with Java server applications. I started programming as a kid in the 1980s, and I’ve programmed professionally since 1996. My main focus are REST APIs, large-scale data, and mobile development. The last six years I’ve worked on large National Science Foundation projects. You can read more about my development experience on my LinkedIn account.