Programming Practice: Writing and Refining Programs

Tick each line you got. Your score builds from the marks on the scheme.

• (a) function, because a value (True or False) must be returned to whatever called it1 mark
• (b) correct pseudocode header with the parameter named, e.g. FUNCTION validateAge(age)1 mark
• (b) condition correctly tests the inclusive range using AND, e.g. RETURN age ≥ 0 AND age ≤ 120(b) condition correctly tests the inclusive range using AND, e.g. RETURN age >= 0 AND age <= 1201 mark
• (b) final answer: subroutine correctly closed, cao, e.g. FUNCTION validateAge(age) RETURN age ≥ 0 AND age ≤ 120 ENDFUNCTION(b) final answer: subroutine correctly closed, cao, e.g. FUNCTION validateAge(age) RETURN age >= 0 AND age <= 120 ENDFUNCTION1 mark

Nothing ticked yet - 4 available

Tick each line you got. Your score builds from the marks on the scheme.

• total initialised before the loops, e.g. total = 01 mark
• outer FOR loop correctly iterates over the rows, e.g. FOR row = 0 TO 21 mark
• inner FOR loop correctly iterates over the columns, e.g. FOR col = 0 TO 31 mark
• total correctly updated inside the inner loop, e.g. total = total + seating[row][col]1 mark
• final answer: correctly structured algorithm with both NEXT statements and OUTPUT total placed after both loops end, e.g. total = 0, FOR row = 0 TO 2, FOR col = 0 TO 3, total = total + seating[row][col], NEXT col, NEXT row, OUTPUT total1 mark

Nothing ticked yet - 5 available

Tick each line you got. Your score builds from the marks on the scheme.

• a well-developed, coherent discussion that explains at least two specific refinements (e.g. renaming identifiers, extracting a subroutine, adding comments) and links each to a genuine benefit such as readability, maintainability or reduced duplication, and reaches a justified evaluation of whether the effort is worthwhile for this specific short, personal program.2 marks
• clear points made about refining the code, covering more than one type of improvement with some explanation of its benefit, but with a less developed link to the benefits, or a weaker/unsupported evaluation of whether the changes are worth making.1 mark
• basic or list-like statements about improving the code (e.g. 'use better variable names' or 'add comments') with little or no explanation of why this helps, and no real evaluation.1 mark
• no relevant content, or the response does not address refining the code.1 mark
• renaming single-letter variables to meaningful identifiers (e.g. itemPrice, basketTotal) makes the code easier to read and understand; replacing the four repeated blocks with a single subroutine called four times reduces duplicated code, so a bug only needs fixing in one place; adding comments explains what each part of the code does for anyone reading it later, including the student themselves; these changes do not affect what the program outputs, only how easy it is to read, test and maintain; for a very short, one-off program used only by its author, the benefits of maintainability may matter less, since the student already understands their own code and it may never be changed again; however, even short programs benefit from a subroutine here because it removes real duplication, and the changes take little time to make, so they are still likely worth doing.1 mark

Nothing ticked yet - 6 available