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.

• Secondary 4
• Computing
• 4 activities
• 25 min–45 min

Learning Objectives

1. Analyze how modularization reduces the complexity of debugging a large software system by identifying specific code sections responsible for errors.
2. Justify the criteria for deciding if a block of code should be encapsulated as a function or procedure, considering factors like reusability and single responsibility.
3. Differentiate between functions and procedures by explaining their distinct purposes and return behaviors in programming.
4. Create a simple program that effectively utilizes both functions and procedures to solve a given problem, demonstrating modular design principles.

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Quick Check

After the Pair Refactoring Challenge, present students with a new monolithic code snippet. Ask them to identify two logical blocks and explain in writing how each would be refactored, including the name, purpose, and whether it should be a function or procedure.

Discussion Prompt

During the Whole Class Debug Relay, pause after the flat code debugging round and ask students to share one specific way modularity would have helped them locate the bug faster. Record their responses on the board to highlight the benefits of separation.

Exit Ticket

After the Individual Procedure Practice: Animation Sequences, provide two short code snippets: one function returning a value and one procedure performing an action. Ask students to write a single sentence explaining the key difference in how each block behaves when executed.

Extensions & Scaffolding

• Challenge: Ask students to refactor one of their procedures from the Animation Sequences activity into a function that returns a value used in the animation logic.
• Scaffolding: Provide a partially completed function or procedure template with comments guiding where to place key logic.
• Deeper exploration: Have students compare the performance difference between modular and flat code by timing how long it takes to execute the same animation sequence in both versions.

Key Vocabulary

Modularity	The practice of breaking down a large program into smaller, independent, and interchangeable modules or components.
Function	A block of organized, reusable code that performs a specific task and typically returns a value to the caller.
Procedure	A block of code that performs a specific task but does not return a value to the caller; it performs an action.
Decomposition	The process of breaking down a complex problem or system into smaller, more manageable parts.
Reusability	The ability of code components, such as functions or procedures, to be used in multiple parts of a program or in different programs.