Computing · Secondary 4

Active learning ideas

Modular Programming: Functions and Procedures

Active learning works well for modular programming because students must physically manipulate code to see how breaking tasks into functions and procedures improves clarity. When students refactor messy code or design small modules themselves, they experience firsthand how structure reduces errors and simplifies problem-solving.

• MOE Syllabus Outcomes
• MOE: Programming - S4
• MOE: Computational Thinking - S4

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

Activity 01

• Collaborative Problem-Solving
• 35 min · Pairs

Pair Refactoring Challenge: Monolith to Modules

Provide pairs with a 50-line monolithic program that calculates statistics from a dataset. Instruct them to identify repeated code blocks, convert them into functions and procedures, then test for identical outputs. Pairs share one improvement with the class.

Analyze how modularization reduces the complexity of debugging a large system.

Facilitation Tip

Before starting the Pair Refactoring Challenge, have students highlight repeated code blocks in different colors to visually identify logical units.

What to look for

Present students with a short, monolithic code snippet that performs multiple tasks. Ask them to identify at least two distinct logical blocks within the code and explain how each could be refactored into a separate function or procedure, stating what each new module would be responsible for.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 02

• Collaborative Problem-Solving
• 45 min · Small Groups

Small Group Function Design: Inventory System

Groups receive a problem to manage school inventory: track items, update stock, generate reports. They brainstorm and code three functions and two procedures, justifying choices in a group log. Compile and demo one module class-wide.

Justify the criteria for deciding if a block of code should be a function.

Facilitation Tip

For the Small Group Function Design: Inventory System, provide a starter list of required operations (e.g., add item, remove item) so groups focus on structure rather than requirements gathering.

What to look for

Pose the question: 'Imagine you have a bug in a large program. How does having the code broken down into functions and procedures make it easier to find and fix that bug compared to a single, long block of code?' Facilitate a class discussion where students share their reasoning.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 03

• Collaborative Problem-Solving
• 30 min · Whole Class

Whole Class Debug Relay: Modular vs Flat Code

Divide class into teams. Provide buggy modular code and equivalent flat version. Teams race to debug by passing laptops, noting time and errors found. Discuss differences in a debrief.

Differentiate between functions and procedures in programming contexts.

Facilitation Tip

During the Whole Class Debug Relay, project the flat code version first so students experience the frustration of debugging without modularity.

What to look for

Provide students with two code examples: one defining a function that calculates the area of a rectangle and returns the result, and another defining a procedure that prints a welcome message. Ask them to write one sentence explaining the key difference between these two code blocks based on their output or return behavior.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 04

• Collaborative Problem-Solving
• 25 min · Individual

Individual Procedure Practice: Animation Sequences

Students write procedures for simple graphics animations, like drawing shapes in sequence. They call procedures from a main loop, then swap and run peers' code to identify reusability issues.

Analyze how modularization reduces the complexity of debugging a large system.

Facilitation Tip

In the Individual Procedure Practice: Animation Sequences, remind students to test each procedure in isolation before combining them to avoid compounding errors.

What to look for

Present students with a short, monolithic code snippet that performs multiple tasks. Ask them to identify at least two distinct logical blocks within the code and explain how each could be refactored into a separate function or procedure, stating what each new module would be responsible for.

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

A few notes on teaching this unit

Teach modular programming by having students physically rearrange code before writing new functions, linking the tactile act to cognitive clarity. Avoid starting with abstract definitions; instead, let students discover the value of modularity through frustration with messy code. Research shows that students grasp the purpose of functions better when they refactor code that already works but is difficult to manage.

Successful learning looks like students confidently distinguishing functions from procedures, justifying when to modularize code, and applying refactoring techniques to improve readability. By the end, they should explain why modularity matters, not just describe it.

---

Watch Out for These Misconceptions

• During the Pair Refactoring Challenge, watch for students treating all modules as functions that must return values.

  As students refactor the monolithic code, ask them to label each identified block with a sticky note: 'Does this need to give back data?' If they mark a procedure as a function, challenge them to explain why the return value is necessary by tracing the code flow together.

• During the Small Group Function Design: Inventory System activity, listen for groups arguing that modularization is unnecessary for small systems.

  Have each group count the number of times they reuse a logical block (e.g., searching for an item) in their initial design. Point out how refactoring those blocks into procedures reduces repetition and errors, even in a short script.

• During the Whole Class Debug Relay, observe if students split every line into its own function, assuming more functions are always better.

  After the relay, review the refactored code as a class and discuss which functions feel too small to be useful. Ask students to defend their function sizes based on reusability and readability, using peer feedback to refine their choices.

---

Methods used in this brief

• Collaborative Problem-Solving