Creating Nested if Statements
00:00 Now that you can create some branches, it’s time to create some nested branches. To examine nested branches in a bit more detail, seeing as it doesn’t look at any new concepts, you’re going to look at an example. The example is called Evaluate the Winner.
00:27 The job of your program is to evaluate who won. The catch here is that in golf, the lower score wins, but in basketball, the higher score wins. So you can’t just take the score and say whoever got the highest score won.
00:43 You have to check whether they were playing golf or basketball. Go over to IDLE and start up a new file. To get started on your Evalute the Winner program, you’re going to simulate some inputs here.
You can start that by defining some variables. Say you start with
p1_score for player 1. Let’s put that at
p2_score, let’s put that at
9. Since it’s
"Golf", and lower scores win in golf, player 2 would be the winner in this case.
01:30 Although you won’t be actually taking user input with this program, maybe later you’ll develop it into something that takes user input. You need to determine who won, but there’s two components to that. You need to determine their score, but the way you interpret the scores depend on the sport that’s being played. So the first thing you should determine is what sport is being played.
and again, you can just echo
"basketball" for now. You’ll work on the logic to determine whether they won or not later on. And finally, you can have a fallback because someone might put in a sport that’s not supported by your program.
02:38 There’s a bug in this program right now, as it stands. Can you spot what it is? Basically the input here, you can imagine someone putting in a capital letter to start off with, but you’re checking against a lowercase letter.
So if you save this and run it, you’ll see that it says
Unknown sport! And that’s because of this capitalization of the
"G". So a common pattern to use when taking user input is to cast everything to lowercase, with the
.lower() method on the string.
Now that you are able to identify the sport, you’ll need to be able to identify who won. So start off with golf and work on basketball later. What you can do is nest a whole new
if block within this indented block.
because if it’s not a draw and player 1 hasn’t won, then player 2 must have won. You can add another
elif not have an
else block here, but you want to practice with all the keywords, so you’re going to do ut this way.
How would you extend that for basketball? Well, you can actually just copy-paste pretty much everything in here, and all you need to change is the comparator. So now,
if p1_score > p2_score, then player 1 wins.
06:04 There are a few things that you could do with the code you have so far. Can you spot what it is that you could do to make this a bit simpler and easier to read? When trying to refactor code like this, it’s useful to look for similarities between different indented blocks and see if there’s something in common that you can bring up a level.
So you can say—actually, you can just copy this, link up the whole
if structure—because if you just left this as an
if, then it would do the two checks separately. Delete the first check from both of the inner
if blocks always have to start with an
if. They can’t start with an
But you don’t actually need to put a sport anymore. It will still work and say
It's a draw! It won’t say
Unknown sport! Can you see why this is? Since the
if block goes in order and will first check whether the scores are equal before checking whether the sport is basketball or golf, it has a path to print something and exit the
if block, without even checking the sport. If you wanted to change this behavior, then this refactoring might not be a good idea, but in general, if your program can support more cases, because there aren’t, as far as we know, any sports where an equal score is not a draw, so now your program will support hockey, for instance, although this is more of a side effect, an unintentional side effect.
08:23 If you wanted to do something more explicitly like this, this probably wouldn’t be the best implementation. In any case, refactoring is always full of these trade-offs and musings about what is the best way to write code, but in general, if you can flatten something and make it easier to read and follow, then generally that’s a goood idea.
08:43 And by flatten, I mean take this out from being nested. The Zen of Python says flat is better than nested. And although the nesting level hasn’t changed here—you still have one level of nesting here—the content that is nested is less than before, and you also have less conditions. In the code, you’re only having to check whether it’s a draw once.
09:08 Now with something about refactoring, is that it never seems to be done. You can always do more. You can always make your program work in a slightly different way, and there are always trade-offs.
09:16 There are always things that are good about one way and worse about another way, but by playing with the code, changing it up, seeing how else it might run, what other names you can give the variables, you can really discover and get much better at Python. So give it another shot and see if you can refactor it again.
Become a Member to join the conversation.