(Redirected from Debugging)

A common problem for Scratchers is when a script that may seem to be flawless ends up not doing what is expected, or getting highlighted in red. These are usually normal human errors and can be fixed. This is commonly known as debugging, the term for which originated in the 20th century when Grace Hopper, a computer scientist, removed an actual cockroach from a machine and said she was "debugging the machine".[citation needed]

Inspecting Scripts

Inspecting a script that does not work is often not easy. Finding a problem with a script is difficult because it makes sense to the writer. Often, thinking from the computer's perspective will highlight the issue. For example, to find the sum of the fractions 1/2+1/3+1/4+…+1/100 one may use the following script:

set [n v] to [100]
set [total v] to [0]
repeat until <(n) < (1)>
 change [n v] by (-1)
 change [total v] by ((1) / (n))

This will not work, because on inspecting the script, the "n" variable will be equal to 0 on the last iteration (loop/repeat), and will cause a zero division error.

Other issues can occur when actions do take place but are not seen by the user. For example, if a sprite is hidden or has a ghost effect of 100. A practical example is a continuation of the script above:

say [I have found the sum!]
say (total)
say [Wasn't that great?]

The script will just say "Wasn't that great", because the previous two actions happen in a split second, or sometimes, within a single render cycle of the evaluator. To fix these problems, either use the wait() block in the "Control" section between the blocks, or use the Say () and Wait () block instead.

Sometimes, the error is purely logical and appears sensible only at the moment. These are often the hardest to track down because there is no true "error". For example, accidentally inserting the wrong variable, or changing the order in subtraction will mess up a script without giving a trace. The best way to find these mistakes is to ask a friend. Walk through the entire program, block-by-block, and make sure the chosen friend understands each step. If there is a logical mistake, they will probably catch it.

Preventing Errors

  • The best way to prevent silly mistakes is to have neat, organized code. Order scripts by their functions or order of evaluation will help find mistakes and prevent them.
  • Leave comments wherever a lot of time was spent on a script; this way, if it breaks again, they can be referred back to for a glimpse of how the script worked in the past. Anyone with enough experience should be able to understand the script at first glance.
  • Do not blindly copy scripts from other projects unless that was the intention of the project. Other than moral copy theft issues, chances are the script will not work in the context of the program. To learn how to make easy, integrative tools, see Advanced Clone Usage.

Checking Values

If a value needs to be known to determine whether or not a script is functioning, there are a few ways to find it.

Using the Say () block. The say block can be used to constantly checking a value.

say (((var1) + (var2)) * (var3)) //Outputs the value of (var1 + var2) * var3

Updating a variable. A variable can also be updated constantly.

set [check v] to (((var1) + (var2)) * (var3)) //Outputs the value of (var1 + var2) * var3

These methods can also be used to check a boolean:

say <touching [Sprite1 v]?> //Will say whether or not the sprite is touching Sprite1

Testing Code

Testing a large, complex project is daunting because every change can potentially wreck something.

Often, the best way is to simply run the project again and again. However, large games or animations would be painful to debug like this. Instead, introduce certain testing codes, which can be removed in the final release. For example, to test level 27 of a game, add a script where when "space" is pressed, the game goes to the next level.

To make sure that the code remains functional, automate certain tests. For example, scripts that should return a numerical answer can be automatically tested against some built-in cases:

define get cube of (5)
if <not <(result) = (125)>> then
 say [Oops!] for (5) secs
 say [error with input 5] for (5) secs
 stop [all v]

define test CUBE with (n) expect (k)
get cube of (n) :: custom
if <not <(result) = (k)>> then
 say [Oops!] for (2) secs
 say (n) for (2) secs
 stop [all v]

when gf clicked
test CUBE with (1) expect (1) :: custom
test CUBE with (2) expect (8) :: custom
test CUBE with (3) expect (27) :: custom

Common causes of errors

Invalid operations

Main article: Script#Script Errors

Often, Scratchers write programs with a script similar to the following:

set x to (10)
change x by (-1)
say ((1) / (x position))

This script will cause an error after the 10th repeat of the forever block, when x = 0, as nothing can be divided by 0 in Scratch 1.4. (Divison by zero mathematically returns "undefined" or "no solution" while it programmatically returns an error or "NaN".) When this occurs, the script will be highlighted in red and the ()/() block will turn red. To counter this error, the best way would be to start with x = 10.0001 rather than 10. This way, x will never reach 0, it will hit 0.0001 and -0.9999.

Similar problems occur with square roots, logarithms, and trigonometric functions:

set x to (10)
change x by (-1)
say ([sqrt v] of (x position))// this will error when x = -1.
say ([sqrt v] of ([abs v] of (x position)))// this will not error as abs x is always positive.

Order of Commands

The most common problem for Scratchers is for the commands to be in the wrong order. For example, to make a sprite lunge at another sprite, a Scratcher uses commands:

point in direction (45 v)
wait (0.5) secs
glide (2) secs to x: (54) y: (0)
point in direction (90 v)

but it does not look like the sprite is lunging.

A good solution for this problem is to just move around the commands until the script works. Ex., to make the sprite lunge, the Scratcher moves the "point in direction 90" command to right after the "wait 0.5 secs" command, thus making the sprite look like it's lunging:

point in direction (45 v)
wait (0.5) secs
point in direction (90 v)
glide (2) secs to x: (54) y: (0)


Another common problem for Scratchers is the timing of commands. This is often seen in projects that involve 2 scripts cooperating without broadcasts or variables, such as in the sample project Joke. When timing is not perfect the entire project could be thrown off. But do not worry, here are some ways to solve that problem:

Broadcasts and Variables

Using broadcasts and variables will allow the scripts to coordinate with each other. Broadcasts involve hat blocks, so be prepared for a lot of scripts. Using variables will save scripts. If variables are used in a project like Joke, the "wait until" block will most likely be used. Otherwise the "if" block could be used instead or possibly the "repeat until" block. Either way, the scripts will be more accurately coordinated.

Careful Timing

If broadcasts or variables are strongly unwanted for some reason the amount of time between blocks can be adjusted, by using the "wait () secs" block. This would be easy for a project like Joke but not for a complicated game.

Repeated Process

This method is mainly for very complicated games. To make accurate detection, tests should be repeated a few extra times before activating a reaction. It may be unnoticeable but it takes a small amount of time to run a command. If a test block is repeated, it will give the detection a little bit longer to change itself. An example of this can be found in this project.


Blocks can also revolve around the timer. Scratch's timer can be reset and manipulated, so much can be done with it.


The third and least common reason for scripts not to work would be that the commands just do not work with each other. When this happens, the script will be highlighted in red. The sprite is "stumped". When this is the case there really isn't anything to do about it except to rebuild the script completely, with a different approach.

when gf clicked
say [Hello World!] for (2) secs
if <visible?> then
say [I see you!] for (1) secs

Obsolete Blocks

Main article: Obsolete Blocks

When using older versions of Scratch, blocks may be labeled "obsolete!". These are usually blocks in the newer versions of Scratch and are not compatible with older versions. Using these blocks in the older versions will often cause the script to fail.

In 2.0:

when gf clicked
create clone of [myself v]
reset timer

In 1.4:

when gf clicked
reset timer

Blocks like "say nothing" are hidden in Scratch 1.4, but will not cause a script error.

See Also