Your First iOS & SwiftUI App: An App from Scratch

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

You can unlock the rest of this video course, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now

Look at the points method in Game.Swift. At this point, you've simplified your algorithm to calculate the difference down to a few lines of code and that's good, but we can do even better. We can get it down to one line of code. Currently, we've added some code to convert a negative number to a positive number. Basically no matter what, we want to make sure this is a positive number. Well this is kind of a common thing that you need to do, right? So when there's a common thing that's math related, especially like this, it's a good idea to check the Swift Standard Library to see if there might be a function that can help you out. We could dig around in the developer documentation again to find the parts about int or we can let Xcode help us out. Hold option and hover over any of these ints and then click once you see a question mark. Then you can open the documentation for int directly with the link at the bottom. Okay, now that we're here, we can kind of scroll through here to see if there's any kind of handy methods on int that might help us. So we've already seen some of these converting floating point values, we've seen creating random integer. Wait a minute. Here's one that says return the absolute value of a given number. So if I click on that, you might have learned this from math class. Absolute value is a fancy way of saying if it's a positive number, leave it as a positive number. If it's a negative number, multiply it by negative one. So this is basically exactly what we're doing in our algorithm. So we can just use this existing function instead of writing it ourselves. Back in our code, just type in abs and parenthesis. You put in whatever the value is and it returns the absolute value of that and then we can delete our other if else code here. Now go ahead and run the test with command you again and wait a minute and green check marks is great, but next to this in the issue navigator, alright, so like we've seen a couple times in this course, we're getting a warning on this line and this warning, we can click on it, it says the variable difference was never mutated. Consider changing to a let constant. Replace var with let and now it's finally time to talk about why this warning is happening and it leads me to an important discussion about let versus bar. It turns out Swift makes a distinction between variables and constants. As we discussed in the episode on variables, you can change the value of a variable at any time. However, once you set a constant, you can never change it again. If you try to change it, the Swift compiler will give you an error. The keyword var creates a variable while let creates a constant. In the first versions of your algorithm, you declared the difference as a variable because the value could change depending on your if else statement, but in the latest version, once you calculate the difference or the awarded points, they will not change again before the method finishes, so they could really be a let or a constant rather than a variable. When you declare a value that will never change in Swift, it's better to make it a constant with let. This makes your intent clear, which in turn helps the Swift compiler understand your program better. A good rule of thumb is to prefer to use constants with let as much as possible and only use variables with var if you need to change the value later on. That way the Swift compiler can optimize your code as much as possible. That's why we've been seeing these warnings in Bullseye so far. It's because Xcode noticed that in some cases, we've been using var to declare variables but those variables never changed so we could have used let and it helpfully notified us about that. So let's go through and update those variables to constants, which should resolve all our warnings and get Bullseye in a clean state. So back in Game.Swift, we have this variable difference, which is never gonna change once we set it to an initial value, so we can just change that to a constant instead of a variable since we don't need it to change and we just repeat that for these other items that don't change. For awarded points, we could do the same. By the way, this is one of those cases where the error message in code is actually really good and even includes a fix it button. I can click and it'll replace the bar with let for me, which is really convenient sometimes. The issue navigator can be really helpful to find warnings in other files. I can just click on this one under content view and it'll take me right there. So this line here, we're creating a rounded value. We set it to an initial value. We never change it, so that's an example where we should have a let and if we remember in Bullseye tests, we actually were creating a couple of variables here that never changed. So in both tests, change guess and score to constants with the let keyword. Now to make sure I've gotten all of them, I can check the issue navigator here which shows all of the errors or warnings across the project and we don't see any. I'm just gonna make sure everything still works. Command B to build and Command U to run our unit tests. Good practice to make sure we didn't break anything. So now we have our code following some best practices of using constants where possible rather than variables and all our tests are passing.