Unit 2 Lab 4: An Introduction to Debugging, Page 5

Debugging Recap

On this page, you will review what you've learned about debugging in Snap!.

One early case of "debugging" was when an actual moth got stuck inside a computer in 1947. Here is a page from Grace Hopper's notebook with the moth pasted in: Photo of the first actual case of bug being found, at Mark II Aiken Relay Calculator, Harvard, 1947

Photo of the first actual case of bug being found, at Mark II Aiken Relay Calculator, Harvard, 1947

Debugging is the art of identifying errors in computer programs and fixing them.

Tips

Don't delete your project and start over. This sounds obvious when you see it written down, but programming students sometimes get angry at their bugs. Remember that if you have a program with 20 blocks in it, and one of the 20 has an error, then your program is 95% correct.
Don't add code to work around the bug. Don't edit the code at all until you understand why it's not doing what you intended, then remove the error. Think: "Debug by subtraction, not by addition."
Don't be hard on yourself. Everyone gets bugs in their programs; it's part of programming.
Reproduce the problem so you are sure you know how to recreate it. This will help you know when you've fixed it.
Isolate the piece of code producing the error. Test pieces of your code separately so you know what's working and what isn't.
Identify the specific cause of the error within that code. Why is that code doing the wrong thing?
Always test your code with different inputs. What if the input is really big, zero, negative, or a decimal? What if the user types something you aren't expecting? What if the user clicks somewhere else?
Love your bugs! They pose an interesting puzzle. Sometimes their incorrect behavior suggests another project:

Talk with Your Partner

Which of these tips would have helped you address an issue in debugging? Pick one and discuss your experience with your partner.

Snap! Debugging and Organizing Tools

You learned about pause all in Unit 2 Lab 2 Page 4: Mandala Design.
You learned about say for in Unit 1 Lab 3 Page 7: Graphics and Art.
You learned about visible stepping in Unit 2 Lab 4 Page 2: Fractal Art.
You learned about displaying variables in Unit 2 Lab 1 Page 2: Debugging and Extending Your Number Guessing Game
You learned about Snap! comments in Unit 1 Lab 3 Page 3: Blocks with Inputs.
You learned about code organization in Unit 1 Lab 3 Page 4: Modify Your Pinwheel.

Use to place breaks in your code and to step through the code at your own pace.
Use blocks in Snap! to get information about the state of your program while it's running.
Use Visible Stepping () to control how quickly Snap! steps through the blocks of your code.
Show the value of variables and sprite attributes to understand the behavior of your program by clicking a reporter, checking the box next to a variable () or sprite attribute () in the palette, or using .
Document your program using comments.
Keep your code tidy. Delete unused blocks, and use Snap! 's "clean up" feature to organize your code.
Use meaningful names for blocks and variables. Some programmers try to save time by naming all their variables x. But if they forget and call a second variable x, this can lead to bugs. So, to make your programs easier to understand and easier to debug, use meaningful names, like horizontal position, instead.
Use abstraction to hide the complexity of code. Abstraction is a way of thinking; you tuck some details into one part of your code and get them working right, and then use that chunk confidently, just as if it were built into Snap!. Some examples of using abstraction include creating custom blocks and using abstract data types. These kinds of abstraction allow you to build and test pieces of your code one at a time, so bugs are automatically isolated.