Unit 3 Lab 1: Dealing with Complexity, Page 6

Debugging Recap

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

: Debugging

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

Tips

Grace Hopper (1906-1992) was an United States Navy rear admiral and pioneer of computer programming. She is best known for her trailblazing contributions to computer programming, software development, and the design and implementation of programming languages.

60 Minutes: Grace Hopper

One early case of "debugging" was when an actual moth got stuck inside a computer Grace Hopper was working with in 1947. Here is a page from her notebook with the moth pasted in.

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

Try to write elegant code. If you're writing a state capitals quiz, then you'll need to store every state and capital in your program, but if you're writing a multiplication quiz you can have the computer calculate the answers. Take advantage of the natural structure of the problem you are solving.

AAP-2.B.7

Use abstraction to hide complexity. Isolate some details into a custom block, and get that working right. Then use that abstraction just as if it were built into Snap!. Abstraction allows you to build and test pieces of your code one at a time; it makes your code more readable. If you can't see an entire script on your screen at once, it's time to stop and organize your code.

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.

How to find a bug:

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. Look for extreme cases: 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?

Don't add code to work around a bug. In fact, don't edit buggy code at all (except to add temporary debugging code) until you understand the problem; 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.

If it works, it's correct. You don't need to ask your teacher "Is this right?" The computer will tell you whether your solution is correct, and more than one solution may work.

Be open to new ideas. Especially if you learned to program before this course, a few of the ideas in this course might seem strange to you, such as the use of higher-order functions instead of looping. One of the goals of BJC is to introduce you to different ways of organizing a program that make the code shorter and don't have as many openings for bugs to creep in.

Love your bugs! They pose an interesting puzzle. Sometimes their incorrect behavior suggests another project:
buggy triangle turns into star by repetition

buggy triangle turns into star by repetition

Which of these tips would have helped you debug one of your projects? Pick one and discuss your experience with your partner.
Choose one of these tips that doesn't make sense to you, and try to figure out why we included it.

Snap! Debugging and Organizing Tools

You learned about

Pause all in Unit 1 Lab 3 Page 5: Using Pinwheel to Make Polygon
Say in Unit 1 Lab 3 Page 2: Angles and Turning
Visible stepping in Unit 1 Lab 3 Page 1: Exploring Motion
Displaying variables in Unit 2 Lab 1 Page 3: Debugging and Extending Your Number Guessing Game
Snap! comments in Unit 1 Lab 3 Page 3: Blocks with Inputs
Code organization in Unit 1 Lab 3 Page 4: Modify Your Pinwheel

places breaks in your code so you can step through the code at your own pace.
can give you information about the state of your program while it's running.
Visible Stepping () lets you control how quickly Snap! steps through the blocks of your code.
Ways to show the values of variables and sprite attributes:
- Clicking a reporter will show the value of a variable or sprite attribute.
- Checking the box next to a variable in the palette () will also show the value of that variable or sprite attribute.
- lets you do the equivalent of checking the box for script variables, which aren't in the palette.
Comments let you document your program.
The "Unused blocks..." option in the Snap! File menu will eliminate blocks you no longer need. This is often useful when you've loaded a library but you only need one or two blocks from the library.
The "clean up" option in the right-click (or control-click on a Mac) menu of the scripting area background will reposition scripts on the page so they don't overlap.
AAP-1.A.2
Snap! lets you use more than one word in the name of a block or variable. 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. To make your programs easier to understand and debug, you can use meaningful names, such as horizontal position, instead.