Rik explains…Debugging your code

Code Club’s Senior Content and Curriculum Manager, Rik Cross, is not only in charge of creating the amazing projects in our curriculum – he also runs a Code Club in his local school in Leeds. His brain is full of amazing knowledge that we thought we ought to tap into more regularly, so we’ve started a blog series, which we’ve dubbed “Rik explains”. This blog tackles a common issue a lot of volunteers face in Code Clubs: fixing bugs in Scratch…

---

Something I sometimes see in my own Code Club is children putting up their hand and saying “My code doesn’t work” and sitting back and expecting me to fix it!

Often, it can be a lot of code, developed over a few weeks. As I’ve not written the code myself, initially I don’t know how to fix their code any more than they do. As I’m helping children to fix their code, I try to share my thought process with them, in the hope that I can empower children to fix their own code, especially at times when I may not be on hand to help them.

Here are some practical techniques that can be used to debug Scratch code….

1) Code is usually read many more times than it is written. It is helpful to comment scripts with their intended purpose, as well as commenting blocks (or sets of blocks) for which the effects aren’t immediately obvious.

2) As projects get larger, it can often be frustrating to run an entire script just to check whether the last few newly added blocks work as expected. Groups of blocks can be separated from their containing script and clicked, allowing them to be tested in isolation. They can then be dragged back into the main script once they have been tested.

3) It helps to make script output as visible as possible. Variables can be displayed by checking the tickbox next to the variable name. The variable name will then be displayed on the stage, along with the current value. You can also do the same with some sprite and project properties

‘Say’ blocks can also be used to make code output more visible, and individual blocks can be tested by simply clicking them — they don’t need to be attached to a script in order to be run!

 

4) Slowly stepping through scripts can be achieved through the use of ‘wait’ or ‘wait until key pressed’ blocks, slowing down the execution of a complex or fast-moving code;

5) Testing expected and unexpected user input can lead to making a script more robust. For example, take a look at the following script:

What would happen if we ran the above code and answered “‘yeah” or “yep”? We could make the script above more robust by allowing for more than one positive answer:

You could even achieve this by using a list of accepted answers:

6) One final technique I want to mention is the use of cheats as a testing method. Although children often see cheats as a way of making playing a game easier, they were first introduced to make play testing easier. Before a game is released, the entire game has to be rigorously tested, and cheats make this easier. For example. How can you test the last level of a game without having to repeatedly play previous levels? A good cheat shouldn’t be easily discoverable, or interfere with normal play. Combinations of key presses work well, but children also really enjoy creating tiny 1-pixel sprites that can be clicked to activate a cheat or other ‘Easter egg‘.

Sharing techniques with children to spot and fix problems in their Scratch projects themselves will empower them, giving them more ownership of their creations. This is especially important for lifelong learning, at times in the future where there may not be an educator on hand to help them. In fact, many of the strategies covered in this workshop are used in industry by software development teams!