Computing · Year 10

Active learning ideas

Local and Global Variables

Active learning turns abstract scope rules into concrete observations students make with their own eyes. When students debug and refactor real code, they see how variables behave outside the textbook, building lasting mental models. Pair work and relays keep everyone engaged while exposing weaknesses in reasoning early.

• National Curriculum Attainment Targets
• GCSE: Computing - Programming Fundamentals

• 25–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Case Study Analysis
• 30 min · Pairs

Pair Programming: Scope Refactor Challenge

Pairs start with a simple program heavy on global variables, like a basic quiz scorer. They identify access risks, convert globals to locals where safe, and add functions that share state carefully. Test changes and discuss improvements before sharing with the class.

What are the risks of using global variables compared to local variables within a program?

Facilitation Tip

During the Pair Programming refactor, insist each pair writes a one-sentence rule for every change they make to reduce global use.

What to look for

Present students with a short Python code snippet containing both local and global variables. Ask them to predict the output of the program and explain their reasoning, focusing on where each variable is accessible.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 02

• Case Study Analysis
• 45 min · Small Groups

Small Groups: Error Hunt Debug

Provide groups with buggy code snippets showing scope errors, such as undeclared locals or global overwrites. Students predict failures, run the code, trace variables step-by-step using print statements, and fix issues. Groups present one fix and its impact.

Differentiate between the scope and lifetime of local and global variables.

Facilitation Tip

In the Error Hunt Debug, give each small group a printed code sheet with intentional errors so they practice reading scopes aloud.

What to look for

Facilitate a class discussion using the prompt: 'Imagine you are building a simple calculator application. Would you store the current total as a local or global variable? Justify your choice, considering potential issues if the program were to become more complex.'

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 03

• Case Study Analysis
• 25 min · Whole Class

Whole Class: Program Design Relay

Display a program spec, like a temperature converter with user history. Class suggests variables as local or global in turns, votes on designs, and codes a prototype together. Discuss conflicts that arise and refine.

Design a program that effectively uses both local and global variables without conflicts.

Facilitation Tip

For the Program Design Relay, project a running timer and rotate roles every two minutes so everyone contributes under time pressure.

What to look for

Provide students with two scenarios: one where a global variable might be appropriate (e.g., a program-wide configuration setting) and one where a local variable is clearly better (e.g., a temporary counter within a loop). Ask them to write one sentence for each scenario explaining why their chosen variable type is suitable.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 04

• Case Study Analysis
• 35 min · Individual

Individual: Balanced Program Build

Students design and code a short program, such as a shopping list totalizer, using both variable types without conflicts. Include comments on choices, test edge cases, and self-assess scope use.

What are the risks of using global variables compared to local variables within a program?

What to look for

Present students with a short Python code snippet containing both local and global variables. Ask them to predict the output of the program and explain their reasoning, focusing on where each variable is accessible.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

A few notes on teaching this unit

Start with worked examples that students annotate together, marking every variable’s scope and lifetime in colored ink. Emphasize that naming conventions and comments don’t fix poor scope design—they only hide it. Research shows novices benefit from live coding where the teacher models hesitations and fixes, so show your own mistakes and corrections openly.

Students will correctly trace where variables are accessible, predict outputs, and justify choices between local and global scopes. They will identify risks like accidental overwrites and explain when each type fits a design. Evidence appears in their refactored code, debug notes, and design justifications.

---

Watch Out for These Misconceptions

• During the Pair Programming: Scope Refactor Challenge, watch for pairs claiming global variables are always better because they avoid passing parameters.

  Redirect their attention to the refactoring task: ask them to rename each global they remove and explain how the new local version prevents one function from accidentally changing another’s data.

• During the Small Groups: Error Hunt Debug, students may think local variables last until the program ends because they still exist when accessed outside their block.

  Have the group run the code and watch the error message appear on screen, then point to the exact line where the lifetime ended and the variable vanished.

• During the Whole Class: Program Design Relay, students may treat scope and lifetime as interchangeable when debating design choices.

  Prompt the next team to add a comment above their variable showing its first use and its last possible use, forcing a clear distinction between where it can be seen and how long it lives.

---

Methods used in this brief

• Case Study Analysis