Skip to content

Pseudocode Loops and Program Flow

mike-snhu edited this page Aug 25, 2026 · 1 revision

Pseudocode, Loops, and Program Flow

Module Four asks you to design a Higher/Lower Game using pseudocode.

This page reviews the main design ideas without giving you a completed assignment solution.

Pseudocode Is Structured Logic

Pseudocode describes an algorithm in human-readable steps without requiring exact Python syntax.

A generic example might look like:

START example
    INPUT value

    WHILE condition
        INPUT value
    ENDWHILE

    IF condition THEN
        OUTPUT one_result
    ELSE
        OUTPUT another_result
    ENDIF
END example

This example demonstrates structure only. It is not the Higher/Lower Game solution.

Sequence Comes First

A reader should be able to follow the algorithm from start to end.

Before adding branches or loops, ask:

  • What information must exist before the next step?
  • Which steps must happen only after input is valid?
  • Which step produces information used later?

Ordering matters because a program cannot correctly use information it has not obtained yet.

Validation Is a Decision About Input

Validation asks whether input satisfies a requirement.

Generic pattern:

INPUT value
WHILE value is invalid
    OUTPUT validation_message
    INPUT value
ENDWHILE

The important idea is that the repeated section obtains new information. Otherwise, the condition may never change.

Module Four has validation requirements for both the selected bounds and the player's guesses. Use the official assignment wording to design those checks yourself.

Game Decisions Are Different From Validation

After a guess satisfies the range requirement, the game still needs to determine the result of that valid guess.

The assignment requires three possible outcomes:

  • too low;
  • too high; or
  • correct.

That comparison serves a different purpose from input validation.

Keeping those purposes distinct can make the pseudocode easier to read and debug.

Loops Represent Repeated Behavior

A loop describes work that may happen more than once.

For every loop, identify:

  1. the condition controlling repetition;
  2. the statements that repeat;
  3. what can change during an iteration; and
  4. the stopping condition.

Avoid Accidental Infinite Loops

Consider this generic structure:

WHILE value is invalid
    OUTPUT error_message
ENDWHILE

If value never changes, the loop has no obvious path toward stopping.

A useful trace question is:

"What can become different before this condition is checked again?"

Nested Logic Needs Clear Indentation

Loops and decisions may contain other decisions or repeated steps.

Indentation shows which statements belong inside a structure:

WHILE continue_condition
    INPUT value
    IF condition THEN
        OUTPUT result
    ELSE
        OUTPUT other_result
    ENDIF
ENDWHILE

Consistent indentation is especially useful when a loop contains a branch or validation occurs inside repeated game play.

Choose Keywords for Clarity

Useful pseudocode keywords may include:

  • START / END
  • INPUT
  • OUTPUT
  • SET or LET
  • IF / ELSE
  • WHILE
  • REPEAT / UNTIL

There is no single universal pseudocode syntax. The goal is to communicate the algorithm clearly and consistently.

Trace the Design Without Python

You can test pseudocode before writing code.

Choose one required behavior and:

  1. start at the first pseudocode statement;
  2. write down the current values you are imagining;
  3. follow each branch condition literally;
  4. follow each loop until its stopping condition is satisfied; and
  5. record the output or next state.

Useful Module Four traces include:

  • invalid bounds followed by valid bounds;
  • an out-of-range guess followed by a valid guess;
  • a valid incorrect guess followed by another guess; and
  • a correct guess that ends the game.

Common Design Problems to Look For

Without giving away the solution, common structural problems include:

  • checking a value before it has been obtained;
  • generating or using game data before required validation is complete;
  • failing to obtain new input inside a validation loop;
  • treating an out-of-range guess as a normal game guess;
  • omitting one of the three valid-guess outcomes;
  • letting an incorrect guess end the game;
  • allowing a correct guess to continue the guessing loop; or
  • using indentation that makes branch/loop membership unclear.

Keep Python Separate From Pseudocode

Python syntax is not required in the graded design.

For example, you do not need to reproduce exact punctuation, imports, or function syntax. Focus on the algorithm another programmer would need to implement.

After the graded pseudocode is complete, the optional Construct phase lets you translate the design into Python.

Return to Home or continue to Working in Your Course IDE.

Clone this wiki locally