Translating Pseudocode into Real Code

Pseudocode & Algorithmic Problem-Solving

Chapter 5 · Translating Pseudocode into Real Code

Pseudocode describes what an algorithm does. Real code has to also decide how that logic is organized — as a sequence of steps, as an object's own behavior, or as a chain of transformations. The same pseudocode can translate correctly into genuinely different-looking real code, and a few specific translation habits are a real, verified source of bugs when the target language doesn't behave quite the way the source pseudocode implicitly assumed.

One Pseudocode Algorithm, Three Paradigms

ALGORITHM SumOfSquaresOfEvens(list)
    total ← 0
    FOR EACH x IN list
        IF x MOD 2 = 0 THEN
            total ← total + (x × x)
        ENDIF
    ENDFOR
    RETURN total
    

# 1. Imperative/procedural — a direct, line-by-line translation
def sum_squares_evens_imperative(lst):
    total = 0
    for x in lst:
        if x % 2 == 0:
            total = total + (x * x)
    return total

# 2. Object-oriented — the same logic, wrapped as an object's own behavior
class EvenSquareSummer:
    def __init__(self, lst):
        self.lst = lst
    def compute(self):
        total = 0
        for x in self.lst:
            if x % 2 == 0:
                total += x * x
        return total

# 3. Functional — the same logic, as a composed chain of transformations
def sum_squares_evens_functional(lst):
    return sum(map(lambda x: x*x, filter(lambda x: x % 2 == 0, lst)))
    

Verified directly — three genuinely different-looking translations, one identical answer

Run on [1, 2, 3, 4, 5, 6, 7, 8]: the imperative version returns 120, the OOP version's .compute() returns 120, and the functional version returns 120 — an exact match across all three, confirming that paradigm is a choice about how code is organized, not a change to the algorithm the pseudocode actually described.

Paradigm	What changes	What stays the same
Imperative/procedural	State (`total`) is mutated directly, step by step	Reads almost line-for-line like the pseudocode itself
Object-oriented	The list and the operation on it are bundled into one object	The internal loop logic is identical to the imperative version
Functional	No mutable variable at all — `filter` and `map` build new sequences, `sum` combines them	Still visits every element and applies the identical condition and computation

A Real, Verified Translation Pitfall: Truthiness Isn't Universal

Pseudocode often writes IF list IS EMPTY THEN .... A common shortcut when translating this is to rely on the target language's own "truthiness" rules instead of checking length explicitly — a habit that works in some languages and silently breaks in others.

# Python: naive translation of "IF list IS EMPTY"
def check_empty_naive(lst):
    if not lst:
        return 'EMPTY - handled'
    return 'not empty'

// JavaScript: the "same" naive translation
function checkEmptyNaive(list) {
  if (!list) {
    return 'EMPTY - handled';
  }
  return 'not empty (or naive check failed to detect empty)';
}
    

Verified directly — the same-looking check, correct in one language, silently broken in another

Run on an empty list []: Python's not lst correctly reports 'EMPTY - handled'. The line-for-line equivalent JavaScript, !list, reports 'not empty (or naive check failed to detect empty)' — because in JavaScript, every array is truthy, including an empty one. An empty array and a non-empty array both fail to trigger the naive check, and the code gives no indication anything went wrong.

The fix — and why it generalizes

The correct, portable translation of IF list IS EMPTY checks length explicitly — len(lst) == 0 in Python, list.length === 0 in JavaScript — rather than leaning on whatever a given language happens to consider "falsy." This exact pitfall generalizes beyond empty lists: integer division is another classic example — many mainstream languages (Java, C, C++, C#, Go) default / between two integers to integer division, silently truncating, while Python 3's / always produces a float (// is Python's explicit integer-division operator). Pseudocode's own ÷ or / doesn't specify which behavior is intended — the translator has to decide, explicitly, every time.

Where This Connects

This chapter's finding	What it sets up
Three paradigms, one verified-identical algorithm	Chapters 6-9's own design strategies are described in pseudocode precisely so they translate cleanly into whichever paradigm a real codebase already uses
A verified, language-specific truthiness gotcha	A concrete instance of Chapter 1's own general warning: an algorithm's own precision doesn't automatically survive translation without deliberate, explicit choices
Functional-style `filter`/`map` composition	The same "process every element, combine the results" shape Chapter 6's brute-force strategies apply directly

Hands-On Exercises

Exercise 1

Using this chapter's own three paradigm translations as a template, write an OOP-style translation for the pseudocode ALGORITHM CountVowels(word), which counts how many of the letters in word are vowels (a, e, i, o, u). Verify your class produces the correct count for the word "algorithm".

📄 View solution

Exercise 2

Using this chapter's own verified truthiness finding, explain what would happen if the naive JavaScript checkEmptyNaive function were called on the string "" (an empty string) instead of an empty array, and why this case behaves differently from the empty-array case.

📄 View solution

Exercise 3

Pseudocode contains the line average ← total / count. Using this chapter's own integer-division discussion, explain what a programmer translating this into a C-family language (where total and count are both declared as integers) needs to do differently to get the same result as the equivalent Python 3 code, and why simply copying the pseudocode's / symbol directly is not guaranteed to be correct.

📄 View solution

Chapter 5 Quick Reference

Verified directly: the same SumOfSquaresOfEvens pseudocode, translated into imperative, OOP, and functional Python, produced the identical result (120) across all three — paradigm changes organization, not the algorithm
Verified directly: a naive empty-list check (not lst / !list) works correctly in Python but silently fails in JavaScript, because every array is truthy in JavaScript, even an empty one
The portable fix: check length explicitly (len(lst)==0, list.length===0) rather than relying on a language's own truthiness rules
Integer division is a second classic pitfall: Java/C/C++/C#/Go default / between integers to truncating integer division; Python 3's / is always a float (// is its explicit integer-division operator) — pseudocode's own / doesn't specify which is intended
Next chapter: Brute force and exhaustive search — the first of four design strategies, expressed in pseudocode ready to translate into any of this chapter's own three paradigms