So, now that we’ve covered the concept of optionals and you know how those work, we’re going to take a look at the more practical side and look at a way to implement this is a way that makes sense.
Check using If’s
Optionals give us the option to do error handling if seething is not going as expected and also make decisions based on the state that our object has. What we’re going to use to do that are if statements. Those If-Statements allow us to check for states our object. We can check if some conditions are met and if we have a certain object or if for example a user has not entered text yet. We could in this example decide to display a warning that no text has been entered.
We can use If-Statements to discover those problems. For example like this.
We’re now going to take a quick look at our Xcode project to see how we could use those if statements.
Demo in Xcode
Okay, back at it again. This code looks nice and works really well and we can now decide to go shopping if we don’t have any eggs in the fridge. That’s what our optionals are now doing for us.
Our optional „defines“ the state of our Fridge. It defines wether we have eggs or not and based on this condition, we can make a decision on what we’re going to do. Either owe go shopping or make scrambled eggs.
Now those If-Statements have a problem. It seems like a detail, but stay with me here. Right now we’re looking if our eggs are not there. The not is important in this context. I however feel that it would make much more sense and make the code more readable, if we could just check if the eggs are there. So we would not be looking at if our eggs are not there, instead we’re looking if the are. It might seem like a detail but it makes the code much easier to understand and it will make more sense if you see the concept I’ll introduce to you right now.
Because for this small detail, as small as it seems, swift offers a very handy way to solve it. Swift offers a way so we don’t have to negate our condition. So we can say „If our eggs exist, continue executing, If not, do something different.“
Now this concept is called „guard“. While we won’t go into too much detail of what you can do with guards, we will touch a little bit on the concept so you can grasp what they do.
If it helps you understand, you can think of guards as an „inverted if-statement“. So if the condition is met, it does not enter the code that is typed into the guard body and if the condition is violated it jumps into the guards „else“ body.
Now let me just state again, that this looks like a small detail, it might seem tiny but It is in fact something that is really really helpful and I prefer to use those guard in swift as much as possible, because they make the code much more transparent.
And heres what they look like. We’re checking if our optional is not nil, else we execute the code of the guard body. So we don’t have two scopes like you would with an if-else. So if the condition is met, the guard is just ignored and your function, loop or whatever just continues running.
This last slide is just here to highlight the difference between if and guard statements.
As you can see, on the left side you have the guard, on the right side there’s the if. Right where the common „do the work“ is, that’s the spot where the code will be executed if the condition is met. You can clearly see that the guard acts as an inverted if statement. We can now use the else block behind the guard to execute code if our condition is violated. While with an if statement, we would have to put everything inside the if block that we would want to get executed if the condition is met.
The problem with the if statement at this point is that this could easily stack up and create a so called „pyramid of doom“. That’s when we use an if-statement inside an if-statement inside if-statement and so on. This would add up over time.
Our guard in comparison does not work like that. We can se else and about or leave the function of bring up a warning and if not we can just continue in our function.
Let’s just take a look at what this would look like in our example.
Demo in Xcode
Now that you’ve seen how this plays out in code, I have to say that this is not only for readability. There is another upside of this concept. That’s what the next chapter focuses on.