01 | A MENU WITH SEVERAL POSSIBLE CHOICES

A learning program offers three menu options: lessons, revision and help. It receives one choice and needs to display the corresponding message.

You could write nested IF statements testing whether the choice equals one, two or three. When several simple alternatives depend on the value of the same variable, CASE can express the choice clearly.

CASE selection chooses one branch according to a variable’s value. The labels state the individual values that match each branch.

CASE is still selection, just as IF is. It does not automatically repeat the menu, validate the input type or carry out a full feature simply because a label mentions it.

02 | THE CAMBRIDGE CASE FORMAT

Here is the core menu decision. Assume Choice is declared INTEGER and already holds a supplied whole-number value.

CASE OF Choice
  1 : OUTPUT "Lessons selected"
  2 : OUTPUT "Revision selected"
  3 : OUTPUT "Help selected"
ENDCASE

CASE OF names the variable being inspected. Each case places a value before a colon and its statement after the colon. ENDCASE closes the selection.

With Choice equal to two, only the revision message is output. The program does not execute the lesson and help statements as well.

03 | ONE MATCH, THEN CONTINUE

Cambridge defines the cases as tested in sequence. When a matching case is found, its statement executes and the CASE statement is complete.

CASE OF Choice
  1 : OUTPUT "Lessons selected"
  2 : OUTPUT "Revision selected"
  3 : OUTPUT "Help selected"
ENDCASE
OUTPUT "Menu cycle complete"

For Choice two, the first case does not match, the second matches, and the third is not tested. The selected output is followed by Menu cycle complete.

The common statement after ENDCASE runs after the decision. It is not part of the final listed branch merely because it appears near it.

This notation has no fall-through between matching branches. Do not add another language’s break keyword or assume that following case statements also execute.

04 | OTHERWISE HANDLES NO MATCH

What should happen for Choice seven? Without an OTHERWISE clause, none of the listed branch statements executes, and control continues after ENDCASE.

Include OTHERWISE when you want an explicit alternative for unmatched values.

CASE OF Choice
  1 : OUTPUT "Lessons selected"
  2 : OUTPUT "Revision selected"
  3 : OUTPUT "Help selected"
  OTHERWISE OUTPUT "Unknown choice"
ENDCASE

OTHERWISE must come last. It runs only when none of the preceding cases applies. It does not run after a successful match.

Use the Cambridge form shown here: OTHERWISE followed by its statement. It is not an extra numbered case and does not require a value or colon.

05 | TRACE MATCHED AND UNMATCHED VALUES

Trace the supplied value exactly. If Choice is seven, do not silently replace it with a valid option before following the code.

The message describes the branch taken. In this teaching example, selecting lessons only displays a message; it does not load a lesson page.

A trace may also need to record menu prompts before input and a common closing message after the decision. Do not count only the selected branch output.

06 | TRY A MENU DECISION

Enter one, two or three, then try another whole number. Predict the selected branch before checking the trace.

Each submission demonstrates a separate evaluation. The demo checks that its form value is a whole number; the CASE then handles matched or unmatched choices. The algorithm itself contains no repetition.

07 | READ A COMPLETE MENU ALGORITHM

Declarations, prompts and input make the decision usable. Assume the supplied choice is a whole number; it may be outside the listed options.

DECLARE Choice : INTEGER
OUTPUT "1: Lessons"
OUTPUT "2: Revision"
OUTPUT "3: Help"
OUTPUT "Enter your whole-number choice"
INPUT Choice
CASE OF Choice
  1 : OUTPUT "Lessons selected"
  2 : OUTPUT "Revision selected"
  3 : OUTPUT "Help selected"
  OTHERWISE OUTPUT "Unknown choice"
ENDCASE
OUTPUT "Menu cycle complete"

For input two, there are four menu/prompt outputs, one selected branch output and one common closing output. The user’s two is an input event, not an OUTPUT instruction.

A prompt tells the user the intended options. OTHERWISE gives feedback for an unmatched choice, but it does not itself request another input. Retrying would need a loop or another appropriate structure.

08 | MATCH CASE VALUES TO THE DATA TYPE

The case labels should represent the same kind of data as the selector. The numeric label 2 matches an INTEGER choice, while the character '2' and string "2" are different representations.

DECLARE Direction : CHAR
Direction ← 'E'
CASE OF Direction
  'N' : OUTPUT "North selected"
  'E' : OUTPUT "East selected"
  'S' : OUTPUT "South selected"
  'W' : OUTPUT "West selected"
  OTHERWISE OUTPUT "Unknown direction"
ENDCASE

Direction is one character, so the labels use single-quoted CHAR literals. The selected message is East selected.

A STRING selector can use matching double-quoted text labels. Do not assume case-insensitive identifiers mean uppercase and lowercase text values are identical; if input needs normalising, the algorithm must specify that handling.

09 | CASE CAN SELECT AN ASSIGNMENT

A selected branch can assign a value rather than only displaying a message. Suppose zone A costs two, zone B costs three and zone C costs four.

DECLARE Zone : CHAR
DECLARE Fee : REAL
Zone ← 'B'
CASE OF Zone
  'A' : Fee ← 2.0
  'B' : Fee ← 3.0
  'C' : Fee ← 4.0
  OTHERWISE Fee ← -1.0
ENDCASE

For zone B, Fee becomes three. An unmatched zone gives the illustrative sentinel minus one, meaning no valid fee was selected.

If later code displays a payable fee, it must distinguish that sentinel from a real fee. Choosing an error marker is not the same as completing error handling.

Make sure every path that later uses Fee has assigned it a meaningful value or has been handled separately. CASE does not automatically initialise an unmatched variable.

10 | COMPARE CASE WITH NESTED IF

The following IF version expresses the same three simple menu alternatives.

IF Choice = 1
  THEN
    OUTPUT "Lessons selected"
  ELSE
    IF Choice = 2
      THEN
        OUTPUT "Revision selected"
      ELSE
        IF Choice = 3
          THEN
            OUTPUT "Help selected"
          ELSE
            OUTPUT "Unknown choice"
        ENDIF
    ENDIF
ENDIF

Both versions inspect the same supplied choice and select the corresponding message. CASE presents the simple value-to-statement mapping with less nesting.

IF is more flexible when the rule involves inequalities, several variables or combined conditions. The choice of structure should follow the requirement rather than a rule that one keyword is always better.

For example, Score >= 50 is naturally a condition for IF, not a simple value label copied into this CASE format.

11 | KEEP CASES SIMPLE

The Cambridge guidance recommends a single value and a single statement for each case. Keep the examples readable and consider IF for more complex cases.

Use CASE for options such as a numbered menu or single-character direction. Use IF for a range, such as age from thirteen to seventeen, or a rule requiring both payment and available capacity.

Do not invent syntax such as 50 TO 100 or Score >= 50 as a case value for this course’s basic format. Translate the condition using the supported IF notation instead.

Different programming languages offer different switch or match features. The pseudocode rules here are specifically the Cambridge conventions used in this syllabus.

12 | A MENU MESSAGE IS NOT A LOOP OR A COMMAND

If one branch outputs Goodbye, that text does not automatically terminate the program. Any common instruction after ENDCASE still executes unless another specified control operation changes that behaviour.

Likewise, displaying Unknown choice does not repeat INPUT. CASE chooses an action for the current value; iteration is responsible for repeated processing.

A menu that stays open until a user chooses exit needs a suitable loop around its input and decision. That belongs with the iteration lessons, rather than being a hidden feature of CASE.

These distinctions help you trace what the given algorithm actually does, rather than what a familiar interface might normally do.

13 | TEST EVERY BRANCH AND THE UNMATCHED PATH

For a three-option menu, use one, two and three to exercise the explicit cases and a value such as seven to exercise OTHERWISE.

If the selector is CHAR, test suitable matching characters and an unmatched character. Make the assumed representation clear rather than mixing numeric and quoted values.

After changing the menu, retest existing options and the new option. Removing OTHERWISE or placing common code inside a branch can break previously expected behaviour.

14 | COMMON MISTAKES TO AVOID

All branches run: a matching case executes its statement, then the CASE is complete.

OTHERWISE runs every time: it runs only when earlier cases do not match.

OTHERWISE placed first: it must be the last clause.

CASE automatically retries: no repetition is created without a loop.

Quoted and numeric choices mixed: use labels appropriate to the selector’s type.

Unassigned result used later: handle the no-match path before reading a variable that only matching cases assign.

Another language’s syntax copied: use CASE OF, the shown case labels, OTHERWISE and ENDCASE for these Cambridge examples.

15 | EXPLAIN THE SELECTION PRECISELY

For Choice two: “The first label does not match, but the second does, so Revision selected is output. The CASE is then complete, therefore the help case is not tested and execution continues after ENDCASE.”

For Choice seven: “No listed value matches, so the final OTHERWISE statement outputs Unknown choice. The decision then ends; it does not receive another input by itself.”

For structure choice: “CASE suits this menu because one variable is compared with several individual values. IF is more appropriate for a threshold or combined condition.”

The next lesson introduces count-controlled FOR loops. You can then combine selection with repetition while still tracing each structure’s separate job.