MP Debugging Part 0

Between this lesson and a second that also focuses on debugging, we’ll be developing a checklist that we’ll expect you to have followed before you can receive help on the help site. But we also expect that, by following these simple steps, you’ll find your mistakes faster, with less frustration, and needing less help from us. So let’s get to it!

Debugging Is Not Developing

Debugging Is Not Developing

Before we get started, we should emphasize that this guide is focused on how to figure out why your code is not working as expected. It assumes that you’ve tried to solve the problem, but your code either isn’t passing the tests or is crashing. These steps are not intended to be used starting from scratch. Our other MP lessons provide plenty of tips for getting started and understanding what you need to do. This is about what to do when things go wrong—as they inevitably do…

Step 0: Tidying Up

Step 0: Tidying Up

Whenever you’re debugging, an important first step is simply to tidy up your code so that you can more easily understand what’s going on. Depending on how you work, that might involve:

• running the autoformat task that we’ve provided
• using the built-in code reformatting shortcut in Android Studio
• removing or moving out of the way any big chunks of commented code that you might have lying around

Overall our goal is to tidy up our source code so that we can more easily understand the code that we’ve written, and continue on with the debugging process. Let’s look at this using an example drawn from MP0.

Step 1: Understanding the Problem

Step 1: Understanding the Problem

On some level, debugging is an investigative process. Something is not working properly. We’re trying to determine why not.

However, it’s hard to make much progress without a clear idea of what is going wrong! This means being able to say more to the course staff member helping you than “it’s not working” or “I’m not getting the points”. Over the days and weeks ahead, staff will increasingly respond to this level of vagueness by asking you to narrow down the problem first, before they are willing to provide one-on-one assistance.

At this stage, our goal is to be able to provide a clear and concise explanation of what is wrong with our code. Imagine you’re explaining the problem to an inanimate object, like a rubber duck. There’s actually a name for this: rubber duck debugging.

For your project, the test suites represent the expected behavior. As a result, identifying the problem usually requires understanding what the test suites are expecting to happen. Happily, they are fairly well-commented, and designed to be straightforward for you to use. Let’s talk through how to do this using an example from MP1.

Step 2: Adding Log Messages

Step 2: Adding Log Messages

With a clearer idea of what’s going wrong, our next steps focus on what is happening, paying attention as we go to how the behavior of our code might not match up with expectations. Bugs in code frequently result from a mismatch between our assumptions about what the code is doing, and what it’s actually doing.

One of the best ways to test our assumptions is through well-placed log messages. Log messages—also known as printf debugging, after the equivalent of println in the C programming language—is a ubiquitous, if sometimes maligned debugging technique. printf debugging works by inserting log messages into the code, running the tests, and using the output from the print statements to help understand what is going on. You can use Android Log.d statements, or good old println, to both determine of certain code paths are being executed, and to examine the values of variables as your code executes.

Again, let’s walk through a simple example drawn from MP1.

Summary

Summary

That’s all for this lesson! But, to recap, here are the steps that we’ll expect you have to completed before you ask for help using the help site or forum:

1. Tidy up your code, so that you and we can read it
2. Identify the problem by examining the test cases and being able to explain how your code is behaving differently than expected
3. Add log messages to help test hypotheses and understand how your code is actually behaving

More Practice

Need more practice? Head over to the practice page.