This episode continues adding to the 5-day email course that shows you how to build a game. The emails contain descriptions of the code. This episode mainly focuses on how the habit of continuous delivery and making distinct steps will help you write better software. Especially when there’s a team involved.
At one point, we move some output text to it’s own method called playGame and I explain why this is important and why you should consider refactoring your code first before making any functional changes.
Listen to the full episode or read the full transcript below.
Transcript
The first thing I did when building this game was to start outputting some text. Asking if the user wants to play the game seems like a good thing to do. This is called a prompt because it lets the user know that something is expected. It’s always a good idea to give the user guidance for what’s expected which is why the string contains the y/n at the end.
To read the user’s response, we first need a variable of the correct type to hold the response. We’re looking for a y or an n which are both single characters so we need a variable of type char. Reading the input looks a lot like writing only we use cin instead of cout and change the direction of the arrows to point in the direction that the information will be flowing.
Then by checking if the input equals a y, we display a simple message that the user won. Otherwise, we say goodbye.
It’s not much of a game, right? You might even think it’s kinda boring. All I can say is imagine if it wasn’t a game.
It’s good to establish the habit to make small steps. As you get more comfortable with programming, your steps will get bigger. But always try to keep your code within a couple hours of being able to build and run. Even if it’s not yet done, just adapt the approach we’re taking here to a larger scale.
I still like to have something ready that can run at least every half hour. It may take days or weeks before a major component is ready and if I let things go that long before trying to run my code, it just won’t work. I’ll end up spending longer at the end trying to get everything running than I would if I had made sure to keep it running all along.
You’ll also find this approach works better with a team. Making small adjustments along the way is definitely the way to go.
So what I do is after each step, I’ll ask myself what can I do to make this better or more full featured. Our game right now just asks if we want to play and prints a message that we won if we type a y and prints a goodbye message for anything else.
We can make 2 easy changes at this point.
First, let’s get more specific about the inputs. Checking for a y is good but let’s add another check for just an n and print the goodbye message only when the user types an n. For any other input, we will remind the user that the valid keys are y and n and wait for more input. This version adds a loop with an if, else if, else statement.
Another skill you’ll develop as a programmer is learning how to find reusable portions of your code and moving them into their own methods. For what we have so far, the message that says we won doesn’t quite belong in the main method. The purpose of main is to give your program an entry and exit. The goodbye message though does fit very nice with the purpose of main.
This is the type of thinking that you’ll get used to and is why for the next step, I moved the winning message into its own method called playGame. It makes sense at least for now that playGame will eventually know for sure if the game was actually won or not.
For right now, just moving the winning message to its own method is enough. We don’t have to do anything else. In fact, if you try to both restructure code and change the behavior at the same time, that’s when you’ll likely find yourself taking too big of a step and something won’t work right anymore. But was the restructuring the cause or did the new behavior break something?
Anytime you can restructure your code without actually changing the behavior, you’ll be in a better position. Because later I’ll show you how to add automated tests to your code. When you want to prepare for some changes, refactor your code first and keep as much of the existing behavior as possible. Then run your tests and make sure they still pass. This will give you a clean place to start the new behavior. You might think after the tests pass, that when you add the new behavior, right? Well, it’s actually better to write new tests cases or update your existing ones first. Run your code and let it fail, then go back and start changing the code so that the tests pass again. This habit will serve you well.
That’s all for this episode. Tomorrow, we’ll continue following the email course. Remember, if you want to follow the code in the email course, you can visit takeupcode.com/wordguess to sign up.