Inputs, Outputs, and Data Handling in Pseudocode

1) Declaring Inputs and Outputs at the Top

Clean data flow starts by stating what information comes in (inputs) and what the algorithm produces (outputs). This is not “code”; it is a compact contract that helps readers understand the goal before reading the steps.

Input/Output header template

ALGORITHM: <name> INPUTS: - <input name>: <informal type>, <constraints/assumptions> - ... OUTPUTS: - <output name>: <informal type>, <meaning>

Keep the header short and practical. If you need assumptions (e.g., “age is an integer”), put them here first; later, you can decide whether to enforce them with validation.

Example: Average of two numbers

ALGORITHM: AverageOfTwo INPUTS: - a: number - b: number OUTPUTS: - avg: number, the average of a and b

Notice that the header describes what flows in and out, without committing to a programming language.

2) Representing Common Data Types Informally

Pseudocode uses informal types to communicate meaning. The goal is clarity, not strict syntax. Use names that reveal intent, and add constraints when they matter.

Common informal types

Lists: what matters to state

• Element type: “list of integers”
• Any constraints: “non-empty list”, “sorted list”, “may contain duplicates”
• How you will use it: “we will compute the maximum” (helps readers anticipate edge cases)

Records: keep fields explicit

INPUTS: - order: record {items: list of record {name: text, price: number, qty: integer}, couponCode: text (optional)} OUTPUTS: - total: number, final cost after discounts

“Optional” is a useful informal constraint. It signals that validation or default handling may be needed.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

3) Reading and Validating Inputs with Clear Decision Blocks

Validation is where many beginner solutions become unclear. A clean approach is: (1) read input, (2) check for missing/empty values, (3) check type/format, (4) check range/business rules, (5) proceed or handle invalid input explicitly.

A practical validation pattern

READ <value> IF <value is missing or empty> THEN HANDLE_INVALID("...") ELSE IF <value has wrong format/type> THEN HANDLE_INVALID("...") ELSE IF <value violates range/rule> THEN HANDLE_INVALID("...") ELSE CONTINUE

HANDLE_INVALID can mean: show an error and stop, show an error and ask again, or return an error result. Choose one and state it.

Step-by-step example: Read an age (integer 0–120)

Goal: read age and ensure it is a whole number between 0 and 120.

ALGORITHM: ReadValidAge INPUTS: - ageText: text, user-provided OUTPUTS: - age: integer (0..120) OR - error: text message (if invalid)

Steps:

READ ageText IF ageText is empty THEN RETURN error = "Age is required." IF ageText is not an integer THEN RETURN error = "Age must be a whole number." SET age = integer value of ageText IF age < 0 OR age > 120 THEN RETURN error = "Age must be between 0 and 120." RETURN age

This version makes the data flow explicit: text comes in, validation happens, and either a valid integer is returned or an error message is returned.

Validating formats: simple checks without language-specific regex

You can describe format checks in plain terms. For example, an email check can be stated as “contains exactly one '@' and at least one '.' after it”.

ALGORITHM: ValidateEmail INPUTS: - email: text OUTPUTS: - isValid: boolean

IF email is empty THEN RETURN false IF email does not contain '@' THEN RETURN false IF email contains more than one '@' THEN RETURN false IF part after '@' does not contain '.' THEN RETURN false RETURN true

Even if a real program would use a more advanced validator, this pseudocode communicates the intended rule clearly.

Validating lists: empty lists and element rules

When an input is a list, validate both the list itself and its elements.

ALGORITHM: AverageScore INPUTS: - scores: list of numbers OUTPUTS: - avg: number OR - error: text

IF scores is empty THEN RETURN error = "At least one score is required." FOR each s in scores DO IF s is not a number THEN RETURN error = "All scores must be numbers." IF s < 0 OR s > 100 THEN RETURN error = "Scores must be between 0 and 100." END FOR SET sum = 0 FOR each s in scores DO sum = sum + s END FOR SET avg = sum / (number of elements in scores) RETURN avg

Notice how validation happens before the main computation, so the computation can stay simple.

Handling invalid input: choose a strategy

• Stop with an error: return an error message/value immediately.
• Ask again: loop until valid input is provided.
• Use defaults: if missing, assign a default value and continue (only if appropriate).

Example of “ask again” for a positive integer:

REPEAT READ nText IF nText is empty THEN PRINT "Enter a value." CONTINUE REPEAT IF nText is not an integer THEN PRINT "Enter a whole number." CONTINUE REPEAT SET n = integer value of nText IF n <= 0 THEN PRINT "Enter a positive integer." CONTINUE REPEAT UNTIL n > 0

4) Writing Outputs as Explicit Messages or Returned Values

Outputs should be unambiguous: either you print a message for a user, or you return a value to another part of a system. Mixing them is sometimes fine, but be intentional and consistent.

Two common output styles

• Interactive style (messages): uses PRINT to show results and errors.
• Functional style (returned values): uses RETURN to provide results (and possibly error information).

Example: Output as a message

ALGORITHM: RectangleAreaMessage INPUTS: - width: number, must be > 0 - height: number, must be > 0 OUTPUTS: - none (prints message)

IF width <= 0 OR height <= 0 THEN PRINT "Width and height must be positive." STOP SET area = width * height PRINT "Area = " + area

Example: Output as a returned value (with explicit error)

ALGORITHM: RectangleAreaValue INPUTS: - width: number - height: number OUTPUTS: - area: number OR - error: text

IF width <= 0 OR height <= 0 THEN RETURN error = "Width and height must be positive." RETURN area = width * height

Returning an error alongside a value is a clear way to represent failure without relying on language-specific exceptions.

Output formatting: state what the user should see

If formatting matters (currency, decimals, units), describe it explicitly.

PRINT "Total: $" + total formatted to 2 decimal places

Exercises: Assumptions and Explicit Invalid-Case Handling

For each exercise: (1) write an input/output header with assumptions, (2) write pseudocode that works under the assumptions, (3) update it to handle invalid inputs explicitly (choose stop-with-error or ask-again).

Exercise 1: Positive integer factorial

Task: compute factorial(n).

• Assumption version: input n is a positive integer.
• Update: handle n empty, non-integer, or ≤ 0.

Starter (assumption-only):

INPUTS: - n: positive integer OUTPUTS: - result: integer

SET result = 1 FOR i from 1 to n DO result = result * i END FOR RETURN result

Your update should add: reading nText, validation checks, and an explicit error output or retry loop.

Exercise 2: Username validation (text rules)

Task: accept a username that must be 3–15 characters and contain only letters and digits.

• Assumption version: username meets the rules.
• Update: if empty, too short/long, or contains invalid characters, output a clear message.

Hint checks (informal): “contains only letters and digits” can be expressed as: for each character, if it is not a letter and not a digit, invalid.

Exercise 3: Average of a list with missing values

Task: compute the average of a list of numbers entered by the user.

• Assumption version: list is non-empty and all entries are numbers.
• Update: handle empty list; handle entries that are empty or not numbers; decide whether to reject the whole list or skip invalid entries (state your choice in the header).

Exercise 4: Record input with field validation

Task: read a student record with fields name (non-empty text) and grade (number 0–100), then output “Pass” if grade ≥ 60 else “Fail”.

• Assumption version: record fields are present and valid.
• Update: handle missing name, missing grade, non-numeric grade, and out-of-range grade with explicit error outputs.

Starter header example:

INPUTS: - student: record {name: text, grade: number} OUTPUTS: - status: text ("Pass" or "Fail") OR - error: text

Exercise 5: Format-sensitive input (date)

Task: read a date in format YYYY-MM-DD and output the month number.

• Assumption version: input matches the format and is a real date.
• Update: handle empty input; wrong format (missing dashes, wrong lengths); invalid month (not 1–12); invalid day range (at least basic check 1–31). State clearly what “valid” means in your pseudocode.