ape-write-pseudocodelisted

# Pseudocode Style Guide ## Structure of a Function Every pseudocode function has exactly three parts: input, output, and body. Use Python-like syntax: `def` for the function signature, a docstring-style comment block for input and output, and indented body lines. ``` def function_name(param1, param2, ...): # input: <what each param represents> # output: <what the function returns or produces> <body> ``` ## Body Rules The body is the core of the pseudocode. Each line is a pythonic, non-functional call that names the operation and its operands -- not English prose. Invent clear, intuitive method or function names. The goal is code that reads like intent, not implementation. - One call per logical step. - Use `object.verb(args)` or `verb(args)` style -- never English sentences. - No type annotations, no real data-structure internals, no language-specific APIs. - Intermediate variable names are fine when they connect two steps. - Never more than one idea per line. ## Control Flow Use `if`, `elif`, `else`, and loops sparingly and only when the branching or iteration is the point of the logic. Conditions are also written as code-like expressions, not prose. ``` if condition_call(args): ... else: ... for item in collection: ... while not done(): ... ``` ## What to Write on Each Line Each line should look like a call you would recognise but cannot actually run. Good patterns: - `nodes.filter_reachable_from(source)` - `entries.sort_by(time