Program comprehension
The investigate stage of TIME is based on a simplified version of the block model of program comprehension proposed by Carsten Schulte. This student and teacher friendly version provides a framework for questioning. It has been shown that a deeper knowledge of syntax and programming constructs allows students to adapt to new commands more easily. Being able to read code is an important pre-requisite to writing code.
Craig'n'Dave six pillars of program comprehension
To facilitate differentiation and provide structure to questions, teachers can follow our six pillars of program comprehension:
Lower order questions:
ITEM
Questions about examples of programming terms.
STRUCTURE
Questions about the syntax of lines of code.
PURPOSE
Questions about what a section of code achieves, returns or outputs.
Higher order questions:
REASON
Questions about why an item or structure is used.
RELATION
Questions about how different parts of a program relate to each other. The implications of moving statements in or out of code blocks.
APPROACH
Questions about other approaches that could have been taken to achieve the same result. The implications for space and time complexity.
Examples
Pillar | Question | Notes |
|---|---|---|
Item | Can you identify an item in the program that is an example of:
Here is a full list of relevant programming terminology. | Asking students to identify the items of their program will enable them to become familiar with the subject specific terminology, helping them to articulate bugs and approaches in the future.
You don’t need to ask students to identify all of these items, select a few. Note that not all vocabulary will be relevant to all programs, but you could encourage the student to state that there are no examples in this case. Students often find this more challenging as they expect there to be an example if you are asking to find one. |
Structure | In this line of code, can you explain:
| These questions explore the syntax of commands and whether the student understands why commands are structured in a particular way.
Getting students to understand qualifiers: arguments and parameters (data) is always enclosed in brackets, that strings are always enclosed in quotes helps their understanding of syntax a lot.
Students become more confident programmers when they can recognise the patterns in code syntax between statements and commands. |
Purpose | Can you explain what this line of code does?
Can you explain what the lines of code between line x and y do? | These questions explore whether a student understands what a block of code achieves. These are particularly relevant for individual subprograms, selection blocks, repetitions and iterations.
Often students copy boilerplate code they become familiar with, follow flowcharts or Parson’s problems, but they don’t necessarily know what that code is for. |
Reason | Why did we use:
| Examine if the program breaks any typical conventions and explore these with the students.
These questions may not be relevant in all programs but students often become familiar with one method instead of the most appropriate method, typically with loops and data types of variables. |
Relation | What is the value of the variable x after this line of code executes?
What would happen if you moved the line of code from line x to be before/after line y instead?
What happens to the value x in the subprogram call when it goes into the subprogram? I.e. which two variables hold the same value?
Why did we need to include the library x… which line of code requires it? | This is an opportunity to check if the student understands the implications of writing a program in a particular way.
Often, they will not understand that a variable needs to be inside or outside of a loop.
They also often misunderstand when a flag variable needs to be assigned/reset before entering a condition. |
Approach | Is there an alternative approach the programmer could have taken that would make the program faster / do less calculations or make it easier to follow? | Most programs can be written in many different ways and still achieve the same output. Some solutions are better than others because of time complexity (how long the algorithm takes to execute) and space complexity (how much memory it uses).
Even simple programs can be more readable with comments and descriptive identifiers.
This is a good place to talk about abstraction too. How a data structure models a real-world object. |
Adding comments to programs
You may notice that the learning programs only contain comments that separate the sections of code. Comments have not been used in Time2Code programs as they should be to describe variables, selections, iterations, or subprograms. This is so that you can challenge students to add these comments to help with their program comprehension. Students could add a comment:
- After each variable is initialised to explain its purpose.
- Before each subprogram to explain its purpose.
- Before each selection: if, elif, match, case to explain the program branch and condition.
- Before each iteration: while, for to explain the loop and condition.
- To any lines of code that look complicated to explain their purpose and approach.
Some comments are included in the solution files.
