Writing a program from a blank page

• The routine
• 1 · Restate
• 2 · Skeleton
• 3 · Pattern
• 4 · Hand table → loop
• 5 · Dry run & assumptions
• Coding on paper
• In the exam room

1 · The routine: five moves

When you freeze on a programming question, you're usually searching for "the idea": the whole program at once. The routine replaces that search with five writing jobs. The first two never need an idea at all, and by the time you reach move 4 the idea usually shows up by itself.

1. RestateWrite one line: input → output, using the question's own example. "5 numbers 2 5 6 4 9, value 10, position 2 → 2 5 10 6 4". If the question has no example, make up a tiny one and work it by hand. You can't write code for an answer you can't produce by hand.
2. SkeletonWrite the parts every program has: #include, int main(void) {, one declaration per thing in your move-1 line, a printf prompt and scanf for every input, a printf for every output, return 0; }. Leave a blank gap in the middle. This is where the "declarations and I/O" marks are.
3. PatternName the job in the middle, using the question's words: accumulate, find the max, count, search, shift, peel digits, try every combination, validate then process. Each name comes with a loop shape you already know (table in move 3).
4. Hand table → loopDo the example by hand, one small step per row, writing down what changes. The rows that repeat are your loop body. Where the rows start is the loop's start, and where they stop is its condition.
5. Dry run & assumptionsRun your code on the example on paper, a line at a time, and check you get the move-1 output. Then write "Assumption: …" for anything the question leaves open (bad input, a zero, the array size). The papers explicitly ask for this.

The sections below show each move on real questions. Each one stops where the routine hands over to the loop you'd write, so you can see how much of the answer the routine produces without an idea.

2 · Move 1 — restate: input → output

This move catches the most common reason for freezing: not being sure what the program is supposed to do. Long questions bury it in a story (vending machines, bank accounts, cricket). Strip the story and keep the data.

Move 1, written on the answer sheet:

/* in:  n = 5,  2 5 6 4 9,  value 10,  position 2
   out: 2 5 10 6 4          (9 falls off the end) */

Notice what that line already tells you: four inputs (n, the n numbers, the value, the position) and one output (the whole array). That's move 2's shopping list.

/* in:  a b 1 2 c d 3 4 [Enter]      one character at a time
   out: 1+2+3+4 = 10;  letters a b c d, highest is d */

Writing "one character at a time" is the useful part: it tells you the input is read inside a loop, one char per scanf("%c", …), until the Enter key's character arrives.

3 · Move 2 — the skeleton the marking scheme pays for

Every program in this course has the same outer shell, and the shell is worth real marks. Here's what the published schemes say:

The template is the same every time. Write it first, top to bottom, with an empty gap where the logic will go:

#include <stdio.h>          /* add <math.h> if you'll need sqrt or pow */

int main(void) {
    /* one declaration per thing on the move-1 line */

    /* a prompt + scanf for every INPUT */

    /* ---- gap: the core logic goes here (moves 3-4) ---- */

    /* a printf for every OUTPUT */
    return 0;
}

Here's the shell for the 2026 cricket question (Q4: ten scores in an array, each between 0 and 200; print total, average, highest, lowest, centuries and a consistency verdict). It is written straight from the question's list of outputs, before any thinking about how to compute them:

#include <stdio.h>

int main(void) {
    int runs[10];                              /* declarations */
    int i, total = 0, highest, lowest, centuries = 0;
    float average;

    printf("Enter runs in 10 matches: ");      /* input */
    for (i = 0; i < 10; i++)
        scanf("%d", &runs[i]);

    /* ---- gap: validate, then compute ---- */

    printf("Total Runs = %d\n", total);        /* output */
    printf("Average Runs = %.2f\n", average);
    printf("Highest Score = %d\n", highest);
    printf("Lowest Score = %d\n", lowest);
    printf("Number of Centuries = %d\n", centuries);
    return 0;
}

That's already most of the 8 shell marks, and it forced three decisions that belong to move 3: total and centuries start at 0 (they add up), highest and lowest have no starting value yet (they need the first score), and average is a float because the output has two decimals.

4 · Move 3 — name the pattern

Almost every program on these papers is built from a few jobs you've met in the loops and arrays labs. The question's words tell you which job:

Most questions stack two or three. The cricket question is validate + accumulate + max + min + count, all in one loop over the same array. The character question is accumulate (digits) + store (letters) + max (highest letter). Naming them turns one frightening question into three small ones you've each done before.

5 · Move 4 — a hand table becomes the loop

This is the move that turns "I know it's a shift" into code. Do the example by hand, one small step per row, and write down exactly which variable or array cell changes in each step. Then look at the rows: the ones that repeat, with only an index changing, are the loop body.

Example: insert 10 at position 2

Array 2 5 6 4 9. The 9 must fall off, the 4 must move into the 9's cell, the 6 into the 4's cell, and then the 10 goes into cell 2. By hand, one step per row:

Now read the table. Steps 1 and 2 have the same shape, a[i] = a[i-1], with i going 4, 3: from the last index n-1 down to just above the position. Step 3 happens once, afterwards. That is the code:

for (i = n - 1; i > pos; i--)     /* rows 1-2: i = 4, then 3 */
    a[i] = a[i - 1];
a[pos] = val;                     /* row 3, once */

Example: add 1 to 1 0 9 9

The same move on the bank-account question. By hand, as you'd add on paper:

The rows that repeat are "while the digit is 9: write 0 and move one left". The row that ends it is "not a 9: add 1 and stop". So the loop runs while the digit is 9, starting from the last index, and one +1 follows it:

i = n - 1;
while (i >= 0 && d[i] == 9) {    /* the repeating rows */
    d[i] = 0;
    i--;
}
if (i >= 0)
    d[i] = d[i] + 1;             /* the last row, once */

6 · Move 5 — dry run on paper, and write down your assumptions

With no compiler in the exam hall, the dry run is how you test. Take the question's own example and trace your code through it, writing a row every time a variable changes. If the last row matches your move-1 output, you're done. If not, the row where it first goes wrong shows you the bug. For the insert question with n = 5, pos = 2, val = 10:

2026 Q3 gives 5 of its 16 marks for exactly this kind of written dry run (the printed tuples and the count), so on questions that ask for one, it's marks, not just checking.

Assumptions. Both recent papers say it in the instructions. 2025: "If you feel that something is missing in any question, please make your own assumption, and state it clearly in your answer." 2026: "If you think something is really missing, you can assume and proceed, but mention your assumption." Examples from these papers:

• Quadratic: "Assumption: a ≠ 0" (otherwise it isn't a quadratic and the formula divides by zero).
• Smallest number from the digits: "Assumption: the answer must stay a 5-digit number, so a 0 digit can't go first" (or the opposite, stated). The question never says which, and the model answer quietly picks one.
• Characters until Enter: "Assumption: at most 100 letters", which is the size you gave the array.
• Insert at a position: "Assumption: 0 ≤ position ≤ n − 1".

7 · Coding on paper: habits and the silent killers

Writing code by hand has its own failure mode: small slips that a compiler would catch. Three habits prevent most of them.

• Write every brace pair at once. When you write {, write the matching } a few lines below straight away, then fill in between. Unbalanced braces make examiners guess what you meant.
• Indent 4 spaces per level, even on paper. It shows which lines are inside which loop, for you and for the examiner.
• One statement per line, and a semicolon on every statement line, except lines that end in { and the for (…) / while (…) / if (…) line itself. A stray ; after for (…) makes the loop do nothing (a 2025 predict-the-output question tested exactly this).

Then scan your finished answer for these. Each one compiles (at most with a warning) and then runs wrongly, which is why they cost marks even from students who know the logic:

8 · In the exam room

• Budget. The 2026 paper was 90 minutes, with up to 30 of them for the 10 multiple-choice questions. That leaves about 60 minutes for five 16-mark programs: roughly 12 minutes per program. Moves 1–2 take about 3 of those minutes and are the safest marks on the page.
• Stuck at move 4 for five minutes? Leave the shell (moves 1–2) on the page, write your hand table next to it, and move to the next question. Come back at the end. A complete shell with a partial loop scores. A blank page scores zero.
• Read the restrictions twice. 2026 questions forbade things: "only one array", "should not use &&", "at most three if-else", "no if conditions", "only for loops", "no user-defined functions or sorting". A correct program that breaks a restriction can lose the logic marks (2026 Q2(a) paid its 8 logic marks only for "correct logic that satisfies conditions in the q"). Underline each restriction before move 3.
• Finish with move 5. Trace the question's own example through your code. It's the only test you'll get.

Next: the practice page takes every program question from the three past papers through all five moves, with a skeleton marked against its marking scheme and a compiled solution for each. The questions exactly as set, with every other question on those papers, are on the past papers page.