NASA has a list of 10 rules for software development

Context and intent of the rules

• Rules originate from JPL’s “Power of 10” paper, targeted mainly at C for deeply embedded, safety‑critical systems.
• Goal: maximize static analyzability, predictability, and the ability to debug from millions of miles away with minimal observability.
• They’re better viewed as strong guidelines or proposed practices, not NASA‑wide mandatory NPR requirements.
• Several commenters think the linked critique ignores this context and plays “gotcha” games instead of engaging with the rationale.

Recursion, loops, and stack/timing bounds

• Ban on recursion is defended as enabling an acyclic call graph, which allows static stack‑usage analysis and worst‑case execution time (WCET) proofs.
• Recursion and function pointers make formal guarantees about stack and timing either impossible or far more complex.
• “All loops must have a fixed upper bound” is about making WCET provable, not about merely ensuring eventual termination.
• Contrived examples with absurdly large bounds are seen as missing the point; in practice, reviewers would flag unrealistic bounds.

Hardware, radiation, and reliability constraints

• Spacecraft hardware is typically old, rad‑hardened, and extremely resource‑constrained: minimal RAM, often no heap, static allocation preferred.
• Radiation induces bit flips in registers and logic even with ECC‑protected memory; software must assume occasional random corruption.
• Techniques mentioned: watchdog timers, NOP‑filled memory regions to trap wild jumps, dual redundant computers, sometimes lockstep CPUs.

Language choices and coding subsets

• Original context assumes C; some argue for “Rule 0: avoid writing critical code in C” in favor of Ada or tightly controlled C subsets (MISRA‑style).
• Others note newer missions using C++, and even JavaScript for higher‑level scripting, but not for the most timing‑critical control loops.
• Garbage‑collected or soft real‑time languages (Go, Erlang, etc.) are seen as unsuitable for hard real‑time safety‑critical control, though fine elsewhere.
• Debate over Rust/Zig: potentially safer than C, but toolchains, standards, and certification ecosystems are still maturing.

Specific rules and criticisms

• Ban on function pointers and recursion is seen by some as overly restrictive, especially for expressing state machines, but justified for analyzability.
• “Two assertions per function” is widely viewed as arbitrary; some reinterpret it as encouraging explicit pre/postconditions and invariants.
• Defense of setjmp/longjmp as “exception handling” is called out as unrealistic and error‑prone in real C systems.
• Several commenters emphasize that while these rules are overkill for typical web/business software, the underlying principles—clarity, determinism, and verifiability—remain broadly valuable.