Debugging Scratch Code: Multiple Choice Questions for Grade 5 Computer Science

📚 Quick Study Guide

🔍 Debugging: Finding and fixing errors (bugs) in your code. 💡 Common Scratch Errors: Code not running, unexpected behavior, sprites not moving correctly. 📝 Step-by-Step Debugging:
🍎 Read the error messages (if any). ✏️ Check your code blocks carefully. 🧪 Test your code frequently. 🐞 Use the 'comment' feature to explain sections of your code.
🧱 Using 'Say' blocks: Display variable values to check if they are correct. ⏱️ Slow Down Your Code: Use 'wait' blocks to observe the sequence of events. 🛠️ Simplify: Remove unnecessary code to isolate the problem.

Practice Quiz

1. Which of the following describes debugging in Scratch?
   1. Adding more features to your game.
   2. Finding and fixing errors in your code.
   3. Sharing your project online.
   4. Creating new sprites.
2. What is a common symptom of a bug in Scratch?
   1. The code runs perfectly every time.
   2. The sprite moves exactly as expected.
   3. The code doesn't run or behaves unexpectedly.
   4. The project saves automatically.
3. Which of these is a good first step when debugging?
   1. Ignoring the problem and hoping it goes away.
   2. Quickly changing random blocks.
   3. Carefully checking your code blocks.
   4. Deleting all your code.
4. What can the 'say' block help you do when debugging?
   1. Make your sprite talk.
   2. Display the value of a variable.
   3. Change the background color.
   4. Add music to your project.
5. Why might you use 'wait' blocks when debugging?
   1. To make your code run faster.
   2. To slow down the code and observe what happens.
   3. To skip over errors.
   4. 'Wait' blocks don't help with debugging.
6. What should you do if you can't find a bug in your Scratch code?
   1. Give up and start over.
   2. Ask a friend or teacher for help.
   3. Ignore the bug and release the project anyway.
   4. Pretend the bug doesn't exist.
7. Which of the following is NOT a good debugging practice?
   1. Testing your code frequently.
   2. Simplifying your code to isolate the problem.
   3. Making random changes without understanding them.
   4. Reading error messages carefully.