Menu
NASA Power of 10 Rule 5 — Average ≥2 runtime assertions per function. Severity: high.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
NASA Power of 10 Rule 1 — Restrict control flow to simple constructs (no goto, setjmp/longjmp, recursion). Severity: blocker.
NASA Power of 10 Rule 2 — Every loop must have a statically determinable upper bound. Severity: blocker.
NASA Power of 10 Rule 3 — No dynamic memory allocation after initialization. Severity: blocker.
NASA Power of 10 Rule 4 — Functions ≤60 lines (one printed page). Severity: high.
NASA Power of 10 Rule 6 — Declare data at smallest possible scope. Severity: medium.
NASA Power of 10 Rule 7 — Check every non-void return value; validate every parameter. Severity: blocker.
| name | pow10-rule-05-assertion-density |
| description | NASA Power of 10 Rule 5 — Average ≥2 runtime assertions per function. Severity: high. |
Severity: high
Use a minimum of two runtime assertions per function on average across a translation unit. Assertions must have no side effects and must trigger a defined recovery path (not be stripped) in release builds.
Assertions catch what static analysis cannot: violated preconditions, impossible states, broken invariants. Forcing the author to write ~2 per function makes them think through boundaries explicitly.
assert(x++ > 0))NDEBUG, -O for Python)Error handling for expected failures (network down, file missing) — that's normal control flow, not an assertion.
At function entry: validate every parameter against domain constraints. Before mutation: check state invariants. After mutation: check postconditions. Each assertion is a single boolean expression with a meaningful failure message.