Pseudocode, Loops, and Program Flow

Pseudocode, Loops, and Program Flow

Pseudocode describes program logic in structured plain language before executable code is written.

This page explains how to think about the Module Four design. It intentionally does not provide a completed higher/lower game solution.

Sequence

A program still has an overall order even when it contains branches and loops.

Ask:

• What information must be available before the next step can happen?
• Which step can occur only after valid input exists?
• Which work happens once?
• Which work can happen many times?

For example, a program cannot use a valid guessing range until that range has been established. That is a dependency, not a Python syntax rule.

Validation

Validation checks whether input satisfies a rule before the program uses it for the next stage.

This assignment includes two different validation ideas:

• The relationship between the lower and upper bounds
• Whether a guess is within the selected range

Do not treat every validation problem as the same loop. Identify what is being checked and what the user must enter again when the check fails.

Decision Branching

A decision chooses among different paths based on a condition.

For a valid guess, the design needs to account for the possible relationships between the guess and the secret number. Each path should make clear:

• What feedback is produced
• Whether the game continues
• What happens next

Loops

A loop repeats a group of steps.

For each loop in your pseudocode, you should be able to answer:

1. What is being repeated?
2. What condition controls the repetition?
3. What changes during the loop?
4. What eventually makes the loop stop?

If you cannot identify a stopping condition, review the design before implementing it. An unclear stopping condition can become an infinite loop in Python.

Indentation Shows Structure

Indentation helps the reader see which steps belong inside:

• A decision branch
• A validation loop
• The main guessing loop

The exact number of spaces is less important than using indentation consistently enough that the nesting is clear.

Trace the Design

A strong way to review pseudocode is to pretend you are the computer.

Choose values from one of the official sample-output scenarios and move through the pseudocode one line at a time.

Keep track of:

• Lower bound
• Upper bound
• Current guess
• Which condition is true
• Whether a loop repeats or ends

Do not change the pseudocode while tracing just to make the current example work. If you find a problem, finish identifying it, then revise the design and trace again.

Ask for Help Without Asking for the Answer

Good questions focus on a concept, for example:

• How do I show that input should be requested again?
• What is the difference between a branch and a loop?
• How can I tell whether a loop has a stopping condition?
• How should indentation show a decision inside a loop?

Do not ask someone to write the completed higher/lower pseudocode for you. The design itself is the graded work you are practicing.