power-of-ten
Power of Ten
Apply all ten rules to code that will be committed, tested, or run more than once. Skip throwaway scripts, one-off commands, prototypes, and pure config or documentation edits, and honor narrower scoping in a project's own instructions. Check the code you must read or change to complete the task, including relevant entry points, callers, dependencies, and failure paths. Scale the depth of inspection and verification to the amount of touched code and the risk of the change. Do not turn this policy into an unrelated repository-wide rewrite.
Compliance is directional. Leave every inspected or changed area at least as compliant as you found it. When you encounter a local violation, remove it or constrain it when that is safe and within the task. Never introduce a new violation or make new code depend unnecessarily on an existing one. If immediate cleanup would increase risk or expand scope, record the violation, keep the change from worsening it, and give a concrete follow-up. Never weaken behavior, error handling, tests, or verification to claim compliance.
Preserve the ten constraints of the 2006 Power of Ten ruleset while translating language-specific mechanisms into their equivalents. When a language lacks a mechanism, record that fact and inspect its nearest equivalent. Do not treat a weaker substitute as direct compliance. Use the deviation policy when a constraint cannot be met.
For each rule, perform the stated inspection, make the stated change when needed, and collect the stated evidence.
The rules
1. Use structured control flow without recursion
- Inspect: Trace branches, loops, calls, returns, exceptions, cancellation, and cleanup across every changed path. Find unstructured jumps, nonlocal transfers, and direct or indirect recursion, including cycles through callbacks.
- Change: Use structured branches, loops, pattern matching, scoped cleanup, and explicit error propagation. Eliminate arbitrary jumps and direct or indirect recursion. Replace recursive traversal with iteration over a bounded worklist. Keep early returns and structured exceptions only when each exit preserves ownership and cleanup. A termination proof alone does not make recursion compliant.
- Evidence: Enumerate exits and cleanup paths. Inspect the affected call graph for cycles. Exercise success and failure or cancellation paths when control flow changed. For unavoidable recursion, document a deviation with a proven depth limit and stack budget.