Nasa Inspired Coding Rules

NASA-Inspired Coding Rules

Use these rules to make code harder to break and easier to maintain. They are generalized from NASA Glenn Research Center's NPARC Alliance programming guideline for Fortran 90: https://www.grc.nasa.gov/www/winddocs/guidelines/pgmstds.pdf

Source note: the linked document is language-specific and Fortran-oriented. Apply the practices, not the syntax. Do not present this skill as an official NASA standard for every language.

Priority Order

When rules compete, optimize in this order:

1. Maintainability: another engineer can understand, modify, and extend it.
2. Portability: it behaves consistently across supported platforms, runtimes, compilers, and dependency versions.
3. Efficiency: it uses CPU, memory, IO, and network resources responsibly after correctness is protected.

Do not trade maintainability for clever speed unless profiling proves it is necessary and tests protect the behavior.

Core Rules

1. Stay Inside Standard, Supported Language Features

• Prefer standard language features and mature library APIs over compiler, runtime, or framework-specific extensions.
• Isolate unavoidable platform-specific code behind a small interface.
• Document any compiler directive, build flag, unsafe block, FFI bridge, reflection trick, monkey patch, or runtime-specific behavior with why it exists and where it is valid.
• Avoid obsolete features, deprecated APIs, legacy control flow, and compatibility shims in new code.

Language cues:

2. Organize by Purpose and Keep Modules Small

• Write modular code with cohesive files, packages, crates, or modules.
• Name files and directories for their domain purpose, not implementation accidents.
• Put related code together, but keep public interfaces small.
• Prefer one primary abstraction per file unless the local ecosystem convention says otherwise.
• Make dependency direction clear; low-level utilities should not import application workflows.

Good modules can be tested in isolation and explained in one sentence.

3. Make Types, Shapes, and Interfaces Explicit

• Declare variables, fields, parameters, return values, and data shapes explicitly where the language supports it.
• Treat implicit coercion as a risk. Convert deliberately at boundaries.
• Match function calls to declarations in argument count, order, type, and meaning.
• Use named constants for values that may change, encode domain rules, or are easy to mistype.
• For public APIs, encode input/output contracts with types, schemas, validators, or documentation close to the interface.

Language cues:

4. Control Ownership, Memory, and Resources

• Allocate memory and other resources as late as practical; release them as soon as ownership ends.
• Prefer language-native lifetime management: with/context managers, try/finally, RAII, defer, destructors, Drop.
• Bound buffers, arrays, slices, maps, queues, and caches. Validate indices and lengths before access.
• Do not hide global mutable state behind convenience helpers. Pass dependencies explicitly or use a controlled context object.
• Treat files, sockets, database handles, locks, timers, workers, and subscriptions as resources that need a lifecycle.

Review question: "What owns this, and when is it released?"

5. Keep Functions Boring, Single-Entry, and Side-Effect-Aware

• Prefer functions with one clear purpose, explicit inputs, and explicit outputs.
• Avoid hidden side effects in functions that look like pure computation.
• Mark mutation at the interface: naming, types, mut, pointer/reference use, or documentation.
• Keep argument lists coherent. If several parameters travel together, introduce a value object, struct, dataclass, or options type.
• Replace long conditional sections with named helper functions when that makes the main path easier to read.

Functions should be easy to test without constructing the whole system.

6. Make Control Flow Obvious

• Use structured control flow: loops, early returns, pattern matching, guard clauses, and small helpers.
• Avoid goto, labeled jumps, fallthrough-heavy switches, callback pyramids, and deeply nested conditionals unless they are the clearest option in that language.
• Label or comment the end of long blocks only when extraction is not practical.
• Never put multiple meaningful statements on one line.
• For error paths, make cleanup and propagation explicit.

If a reader has to simulate the control flow to understand it, simplify.

7. Handle Input, Output, and Errors Deliberately

• Validate external input at the boundary before it reaches domain logic.
• Check errors from IO, parsing, network, database, subprocess, and serialization operations.
• Preserve enough context in errors to diagnose failures without leaking secrets.
• Use recoverable error types for expected failures and fail fast for invariant violations.
• Make retry, timeout, idempotency, and partial-write behavior explicit for IO-heavy code.

Language cues:

8. Prefer Readable Formatting and Naming

• Follow the project's formatter and linter. If none exists, add or propose one before style grows inconsistent.
• Keep line length reasonable for the codebase and language.
• Indent block contents consistently; avoid tabs unless the language convention requires them.
• Use descriptive names that match domain terminology.
• Do not reuse names that shadow important imports, globals, types, or outer variables.
• Use whitespace to reveal structure, not to create decorative alignment that is hard to maintain.

Readable code should make domain intent visible before implementation mechanics.

9. Comment Intent, Constraints, and Surprises

• Comment why code exists, why an unusual approach is necessary, and which constraint it satisfies.
• Do not repeat what the next line already says.
• Put public API documentation near the API.
• Document key local variables only when their role is not obvious from name and type.
• Add source notes for numerical formulas, protocol details, compatibility hacks, and security-sensitive decisions.

A good comment prevents a future "cleanup" from reintroducing the bug.

10. Compile, Analyze, and Test With Production-Like Settings

• Test with the same optimization, runtime mode, feature flags, and platform assumptions used in production.
• During development, also run stricter diagnostics: warnings as errors where practical, sanitizers, race detectors, type checks, linters, formatters, and runtime bounds checks.
• Keep build and test commands repeatable through standard project tooling.
• Add regression tests for fixed defects and risky rules.
• Treat warning growth as quality debt, not background noise.

Minimum tool expectations:

Review Checklist

Use this checklist before merging reliability-sensitive code:

• Is the code modular, named by purpose, and easy to test in isolation?
• Are external interfaces, data shapes, ownership, and lifetimes explicit?
• Are conversions, casts, nullability, optionality, and error paths deliberate?
• Are arrays, slices, buffers, and collection accesses bounded?
• Are resources closed, released, cancelled, or deallocated on every path?
• Are functions free of surprising side effects?
• Is control flow structured and shallow enough to read without simulation?
• Are constants named and close to the domain rule they represent?
• Are comments explaining intent rather than restating syntax?
• Was the change tested with production-like settings plus strict diagnostics?

Common Mistakes

Output Pattern

When applying this skill, structure feedback as:

1. Reliability risks: concrete breakage risks first.
2. Portability and build risks: platform, runtime, compiler, and dependency assumptions.
3. Maintainability issues: naming, organization, contracts, comments, and complexity.
4. Recommended changes: minimal edits that improve safety without over-engineering.
5. Verification: exact tests, static checks, or runtime diagnostics to run.