Program comprehension

User guide

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:

Block model 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:

  • An argument (in a function call)
  • An array / list
  • A constant
  • A string, integer, float, Boolean variable
  • An identifier
  • A repetition or iteration (over a data structure)
  • An operator
  • A parameter (in a subprogram definition)
  • A qualifier
  • A reserved word
  • A selection
  • A sequence

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:

  • Why are brackets needed?
  • Why is x enclosed in double quotes?
  • What would it mean if double quotes were used around x?
  • Why == is used and not =?
  • What does !=, <, > mean?
  • What is the difference between defining and calling a subprogram?

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:

  • A string instead of an integer, an integer instead of a float?
  • A while loop instead of a for loop?
  • Multiple if, elif statements instead of select, match?

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:

  1. After each variable is initialised to explain its purpose.
  2. Before each subprogram to explain its purpose.
  3. Before each selection: if, elif, match, case to explain the program branch and condition.
  4. Before each iteration: while, for to explain the loop and condition.
  5. To any lines of code that look complicated to explain their purpose and approach.

Some comments are included in the solution files.

Registered in England and Wales: 10442992

VAT Number: 290 9845 58

Telephone: 01452 947500

Email: admin@craigndave.co.uk

Bett Awards 2024 Finalist