CPX21Writing, Testing and Refining Programs

Before typing any code, break the problem down (decomposition) and decide what to leave out (abstraction).

• Decomposition: split the problem into smaller parts: inputs, each calculation or check, outputs. Each part often becomes a subprogram.
• Abstraction: keep only the detail the program needs. A booking program needs ages and seat numbers, not names or hair colour.
• Abstraction in code: a subprogram hides how it works. The main program just calls boxesNeeded (area) and trusts the answer.
• Abstraction in data: name a constant for each fixed value (CAPACITY = 40) and choose a structure that models the problem (a 2D list of records).
• Plan with a structure chart or a short list of steps. Then write the main program as a few calls, and fill in each subprogram.
• A good plan for a long question: (1) list the inputs and outputs the question asks for; (2) list the data you're given; (3) decide the subprograms; (4) decide the loops and checks; (5) code one part at a time, running it as you go.

Decomposing a reading-log program: the main program calls one subprogram per task.

Decomposition

Breaking a problem down into smaller parts that are easier to understand, solve and test.

Abstraction

Removing or hiding unnecessary detail, for example by using a subprogram to hide how a task is done.

Apart from the last question, Paper 2 gives you code to read and improve. Pearson uses eight question types.

• Instructions in the files start with # =====>. Do exactly what each says, at that point in the file.
• Don't rewrite, delete or move the given code unless you're told to. Examiners mark the changes they asked for.
• Save in the COMPLETED CODING folder with the exact name given, such as Q03FINISHED.py. Examiners run the files you save.
• Use the constants and variables the file gives you. Typing the number instead of the constant loses the mark.
• Your IDE must show line numbers, because questions refer to the original line numbers.

Refine

Improve an existing program: fix errors, add features, or make it clearer or more efficient.

Parsons problem

A task where given lines of code must be put into the correct order.

• Work through the flowchart from Start, turning each symbol into code.
• Process (rectangle) → an assignment or calculation. Input/output (parallelogram) → input or print. Decision (diamond) → an if or a loop condition. Pre-defined subprogram (rectangle with double sides) → a subprogram call.
• A decision whose arrow goes back up the chart is a loop: write a while loop. If it only branches forward, it's an if.
• When the loop's decision comes before the steps it repeats, the condition goes straight into the while. Check which exit (Yes or No) carries on looping.
• If the flowchart says “stop when count is greater than 5”, the while needs the opposite: while (count <= 5):.
• Two arrows joining after an if mean the code carries on after the if/else block, unindented.
• Use the constants named on the flowchart. Don't swap them for numbers.

Each flowchart symbol and the Python it usually becomes.

• Pearson's “pseudocode” isn't a special language. It's an informal written description in plain English.
• In a comment-first question, each # =====> comment describes the code to write underneath it. Write that code directly below the comment.
• Read the whole description first, then underline the clues: “as a real number” means float; “repeat until” means a while loop with the opposite condition; “for each” means a for loop; “to two decimal places” means {:.2f}.
• “Until” and “while” are opposites. “Repeat until the total reaches 100” is while (total < 100):.
• Keep the comments in your finished file. They help the examiner see which code answers which instruction.

# =====> Ask for the number of guests, as an integer
# =====> Work out the tables needed, at TABLE_SIZE guests a table,
#        rounding up
# =====> Display the number of tables

Pseudocode (Pearson)

An informal written description of a program in imprecise English, with no strict syntax.

Comment-first coding

A Paper 2 task where the logic is given as comments and you write the code for each one.

The spec names five techniques: layout, indentation, comments, meaningful identifiers and white space.

• Layout: group related statements in Pearson's sections: Import libraries, Constants, Global variables, Subprograms, Main program, each under a banner comment.
• Indentation: Python needs it to mark blocks. Keep it consistent (4 spaces) so the structure is clear.
• Comments: explain the logic of blocks (an if/elif/else, a loop, a subprogram), not every line. A comment that repeats the code adds clutter.
• Meaningful identifiers: trayCounts, not x. Pearson uses camelCase for variables and subprograms, and CAPITALS for constants. Avoid single letters.
• White space: blank lines between blocks; spaces around operators and before brackets (total = total + price, print ("Hi")). Don't double-space every line.
• Use constants for fixed values, so a change is made in one place.
• Break long lines inside brackets, and indent the next line so it lines up clearly.
• Before and after:

  x=[3,14,8]
  for i in x:
      print(i,"trays hold",i*12,"eggs")

  # -------------------------------------------------------------------
  # Constants
  # -------------------------------------------------------------------
  EGGS_PER_TRAY = 12
  
  # -------------------------------------------------------------------
  # Global variables
  # -------------------------------------------------------------------
  trayCounts = [3, 14, 8]
  
  # -------------------------------------------------------------------
  # Main program
  # -------------------------------------------------------------------
  # Show how many eggs each delivery of trays holds
  for trays in trayCounts:
      print (trays, "trays hold", trays * EGGS_PER_TRAY, "eggs")

Pearson's layout for a code file: every statement goes in its section.

Meaningful identifier

A name that says what a variable, constant or subprogram holds or does in the problem, such as seatsLeft.

White space

Blank lines and spaces used to separate blocks and parts of a line so code is easier to read.

• A syntax error breaks the rules (grammar) of the language, so the program can't be translated at all. Your IDE usually highlights it before it runs.
• A runtime error happens while the program runs, when it is asked to do something impossible. The program crashes.
• Python's message names the error and gives a line number. Go to that line first; the real mistake is sometimes on the line just above (a missing bracket or quote).
• Fix errors one at a time, from the top, and run again after each fix: one mistake can cause several messages.

print ("Lap " + lap + " done")

Syntax error

An error that breaks the rules (grammar) of the programming language, so the code can't be translated.

Runtime error

An error that happens while the program is running, when it is asked to do something impossible, such as divide by zero. The program crashes.

• A logic error lets the program run, but it gives the wrong result. Python shows no message, so you find logic errors by testing.
• Examiners report that logic errors are the fixes students miss most often, every year.
• Run the program with data where you know the answer. If the output is wrong, work out which part of the code produced it.
• Trace the code: follow it line by line, writing down each variable's value (a trace table; see Trace tables and errors on Paper 1).
• Add temporary print lines to show values inside a loop, then remove them when you've found the problem.
• Use your IDE's debugger: set a breakpoint on a line so the program pauses there, step through one line at a time, and watch the values in the variable inspector.

Logic error

An error that lets the program run but makes it give an incorrect or unexpected result.

Breakpoint

A marker on a line that makes the debugger pause the program there, so values can be inspected.

Variable inspector

A debugger window that shows the current value of each variable as the program runs.

• Test data is input chosen to check that a program works. Choose it before you run the program, and write down the result you expect.
• A test plan lists each test: the input, why it was chosen, the expected result and, after running, the actual result.
• Test a range check at both boundaries and just outside them, plus a typical value. Many logic errors sit at a boundary.
• Also try data the user might type by mistake: a blank, a word where a number is wanted, a negative number. A program that crashes on these isn't robust.
• The words normal, boundary and erroneous (invalid) data are useful labels, but Pearson's papers don't ask for them by name.
• For random programs, run several times and check every value is in range. For programs that write files, run twice and check the file.

Test data

Inputs chosen to check that a program works correctly, each with an expected result.

Test plan

A table of tests: the data, the reason for it, the expected result and the actual result.

Robust

Able to cope with unexpected or wrong input without crashing or giving wrong results.

• A program is fit for purpose if it does everything the requirements ask, gives accurate output and copes with the input it will meet. Check it against each requirement, using logical reasoning and test data.
• The spec measures efficiency in three ways: the number of compares, the number of passes through a loop, and the use of memory.
• Stop early: when a search finds what it wants, stop looking. Use a while loop with a Boolean flag, not break.
• One pass: work out a total, the highest value and a count in the same loop instead of three loops.
• Memory: don't copy data into a second list you don't need, and don't read a whole file into a list if you can process it line by line.
• One entry, one exit: each loop and subprogram has one way in and one way out. That makes the code easier to follow and debug. break and exit () aren't in the PLS.
• Stopping early with a flag:

  def firstOver (pValues, pLimit):
      position = -1
      index = 0
      found = False
      while ((index < len (pValues)) and (not found)):
          if (pValues[index] > pLimit):
              position = index
              found = True
          index = index + 1
      return (position)
  
  print (firstOver ([12, 18, 25, 31, 9], 20))

• This displays 2. It compares 3 values instead of all 5.

Fitness for purpose

How well a program meets all its requirements, accurately and robustly.

Efficiency

How few resources a program uses: measured by the number of compares, the number of passes through a loop and the use of memory.

Paper 2's longer questions give points for each required feature, plus up to three levels-marked strands of 3 marks each. The last question always has all three.

• Level 1 (1 mark) and Level 2 (2 marks) are “little” and “some” or “most” of the same things.
• The points marks need each feature in the right place. The levels judge the whole program, so a partly working program still earns level marks.
• Attempt every question: examiners reported marks for loops and selection even in programs that didn't fully work.
• Don't add validation the question doesn't ask for: it earns nothing. Do add the validation it does ask for, such as rejecting a blank input.

Solution design

The Paper 2 levels strand for how well the problem has been decomposed and how appropriate the logic, data structures and constructs are.

Functionality

The Paper 2 levels strand for how well the program works when run: requirements met, accurate output, predictable and robust.