Program design: deck of cards
About this video
The video designs a deck-of-cards program for several card games using nested function calls. draw_hand loops to call draw_card, which calls get_suit and get_rank; along the way it uses a newline character for readable output, reads a stack trace to fix a TypeError by making get_rank always return a string, and adds a Boolean parameter for face cards that is passed through each function. It ends by noting the deck isn't stateful, so duplicate cards are possible.
You'll be able to
- design a program by breaking it into small functions that call each other.
- read a stack trace by focusing on the bottom line first.
- explain why a function should always return the same data type.
- pass a parameter through several nested function calls.
Key words
- placeholder return value
- A temporary fixed value returned so you can test other parts before the function is finished.
- newline character
- \n – a backslash followed by n, which Python treats like pressing the enter key.
- stack trace
- An error report showing the path of function calls that led to an error, with the actual error at the bottom.
- TypeError
- An error caused by using values of incompatible types, like adding an integer and a string.
- Boolean parameter
- A parameter that is True or False, used to turn an option like face cards on or off.
Transcript
- [Instructor] Let's design a program with functions and nested function calls. We wanna build a program that lets the user play several different card games. That means every game is going to need to share functionality for dealing a deck of playing cards. The first thing that comes to mind is that I'll probably want a function that can draw a random card from the deck.
I'm thinking I probably wanna represent a card as a string, so this might return something like queen of hearts. For now, I'm gonna go ahead and stick that in as a placeholder return value. The other task I can see wanting to perform over and over again is drawing a hand of cards.
Different games use different hand sizes, so I'll want this to be generalizable. So the function should take in as a parameter the number of cards in the hand. Okay, so how should this function work? I guess really what I want is to draw a number of cards equal to that parameter.
Maybe I accumulate all of those card strings into one giant string and then return that at the end. That sounds like a good use case for a loop. On each iteration, I draw a card and then I concatenate that card to our hand. Before we get ahead of ourselves, let's test out what we did so far by calling draw hand, and to be safe, let's test it out with a few different arguments.
Ooh, okay. That's a little hard to read. What if instead I put each card on a separate line? In Python, we can achieve this with a new line character, which is just a backslash followed by N. Instead of displaying this as it appears, Python interprets this, essentially, as us hitting the enter key.
So now with my hand nicely formatted, I feel confident that my draw hand function works, but I don't want my hand to be full of queens every time. So it's time to go back in and fill in our draw card function. A playing card consists of two pieces, the suit and the rank.
To draw a random card then, I wanna pick a random suit and random rank, which sounds like two different tasks, which means two different functions. Let's start out with the suit, since that only has four options, and we'll import the random module at the top of the file.
Okay, well, we want this function to return either hearts, diamonds, spades, or clubs with equal likelihood. So we'll generate a random number between one and four, and based on that number, choose which suit to return. Then we can go back to the draw card function and replace that hard-coded hearts with a call to get suit.
When I run those draw hand function calls now, I get all different kinds of queens. The last thing we need to add is a get rank function. A playing card can have a rank of ace, two through 10, or jack, queen, king. That means, in total, there are 13 possible ranks.
So we'll generate a number between one and 13. If we get one, we'll return the rank ace, 11 will return jack, 12, queen, and 13, king. Any other rank like eight is just represented by its number, so we can return num. Now, just like before, let's go back to draw card, and call get rank.
Mm. What does this stack trace mean? When we read stack traces that involve function calls, we generally wanna focus on the bottom because that is what'll tell us what the actual error is and what line it came from. The rest of the stack trace just tells us the path of execution the computer took to reach that line.
So it started by executing draw hand, which then called draw card, which then had the error. This type error tells us that we're adding an integer and a string. So get rank must be returning an integer somehow. These cases are definitely returning a string. Mm, but down here, when we return num, num is an integer.
As a general rule, a function should be consistent about which data type it returns, always. That way callers can know what to expect. So since get rank needs to return a string in the ace, jack, queen, king case, we also wanna cast num to a string, before we return it.
There's one last feature we wanna add. Some of our card games don't use face cards, that is, ace, jack, queen, king. Because face cards can either be enabled or disabled, we can support this option with a boolean parameter. And if we don't want face cards, we can just generate a random number between two and 10 instead, that way we're excluding the options one, 11, 12, and 13.
Now, when I call get rank inside draw card, I'll need to pass that parameter, but how do I know if it should be true or false? Well, I don't know. I wanna let the caller decide. So draw card, we'll also take that parameter and pass it through to get rank, and then that extends to draw hand as well.
Oops! And now I need to update my calls to draw hand to take in that extra argument. Now that it's all working, what are the limitations of this approach? Well, the deck I modeled here isn't actually stateful. It's possible my hand has two ace of spades. Depending on our use case, this might actually be a feature because some games use multiple decks or don't want players to count cards.
But in other games where the rules strictly assume exactly one of each card, this might be a bug. For this collection of games, I actually think the simplification is pretty nice, but it might not be for someone else's use case.
Video © Khan Academy, used under CC BY-NC-SA. Watch on Khan Academy. Puzzicle is not affiliated with Khan Academy.