Begin to debug, with Python.
Share a list of common bugs, with Python code examples for learners to use as a reference.
This lesson needs to be group-based: everytime a bug is discovered, the person discovering it must clearly describe why they think this by sharing with the rest of the group.
The group must not move on to the next script until everyone is able to describe why the bug prevents the script from running properly.
Have learners create buggy code for their peers or for the teacher. Encourage creativity in what they write. Share with learners that some bugs are intentional - they might lower security of an app or website. How might a flaw be exploited by people who want to harm others? Encourage learners to research this, either during or after the lesson.
19 of 19 linked standards shown.
| Curriculum area | Linked standards |
|---|---|
| Digital Technologies, Design & technologies: Digital Technologies |
Select a code to read the full standard.
| Curriculum area | Linked standards |
|---|---|
| General standards |
Select a code to read the full standard.
| Curriculum area | Linked standards |
|---|---|
| Health and Wellbeing: Mental, Emotional, Social and Physical Wellbeing | |
| Literacy & English: Listening and Talking | |
| Literacy & English: Reading | |
| Literacy & English: Writing | |
| Technologies: Computing Science |
Select a code to read the full standard.
| Curriculum area | Linked standards |
|---|---|
| Computing, Design and Technology: Computing |
Select a code to read the full standard.
| Curriculum area | Linked standards |
|---|---|
| International Society for Technology in Education (ISTE) |
Select a code to read the full standard.
Finding problems and errors in Python looks different when compared to Scratch, but the end goal is the same: working code. In this lesson, we cover some easy ways to find the problem with our programs and put them to the test briefly. Students will be using the IDLE editor in this lesson to create and modify Python programs.
Debugging in Scratch, emerging knowledge of Python commands
Literacy - proofing, Maths - sequencing
Show a short video about the first example of debugging, in computing.
Warm up activity, go through two or three short scripts from the ppt, with learners offering suggestions what each of the statements do. Each short script will have an error that could easily be missed. Run the scripts on the teacher machine and display the result - perhaps Marty will move, perhaps not. The buggy text should include missing quotations, lower/upper case mistakes, spelling mistakes, conditions that will always be true/false, code in the wrong order,
Have learners look more critically at the scripts to find if they can spot an error / a bug. Have them suggest fixes for the problem. End on a more complex example, providing the equivalent Scratch block. Make sure to try running the code again after discussion / debugging.
Discussion with students around why they think we need debugging and why things don’t always work like we expect when programming. What if programmers didn't take the time to debug? What might happen for a user, like us, when we: go to a website; use a device; play on an app; interact with a calculator; plan a journey, when the program that is necessary, for whatever we use, has a bug? What kinds of problems are possible?
List ideas on the board or have learners record them somewhere. Look back to the code samples from the warm up, try to identify why they might be bugs: why would they stop a program from running, properly?
Students should go into small groups of around 2-3, where each group has access to a Marty .
Students in the group should work together to work their way through the Python treasure hunt where they will have to debug some short scripts to get enough clues to work out a fact about Marty. Each of the first four scripts will have one or more of the bugs already seen in the lesson. As the clues progress, the number of bugs, and complexity of the bugs, should increase. The last script is almost blank; learners need to use commands, from the documentation, that they have not yet written.
Have learners compare written English to written code. Have them think how the two are different: consider dialect, accent, syntax or a person's ability to comprehend what the writer means. How is a computer different, why must we treat the computer differently when writing code?
Imagine what might happen if a computer or program was able to think about what the programmer was meaning when it encounters a bug: might it make things better; might it make things worse? Have learners share suggestions.
