Best Practices Functional

Programming NASA
Created by Shawn McNamme

Created time @13 de outubro de 2025 17:16

Tags

This document outlines NASA-level software engineering best practices

specifically tailored for the implementation and coding phase (Production of Well-
Secured Software - PW), focusing heavily on principles derived from functional
programming (FP) to ensure the scripts are robust, verifiable, and secure in an
embedded/game environment.

NASA-Level Coding and Implementation Best

Practices (Functional Focus)
I. Code Structure, Modularity, and Functional Purity
These practices ensure the implemented software is conceptually clear, easy to
test, and highly resilient to changes, core tenets of Functional Programming (FP).

Practice Description & FP Context Source Citation

Design components (functions or modules) using

information hiding to protect design decisions
most likely to change. Components should be
1. Enforce Cohesive
simple, cohesive, and minimize dependencies. FP
Modularity and
Context: This aligns with defining pure functions
Information Hiding
that isolate internal implementation details,
exposing only necessary inputs and outputs (the
interface).

2. Minimize For any safety- or mission-critical

Component component/function, ensure the cyclomatic
Complexity complexity value is 15 or lower (SWE-220). This
minimizes risk, aids testing, and increases

Best Practices Functional Programming NASA 1

 Practice Description & FP Context Source Citation
(Cyclomatic reliability. FP Context: Achieve this by
Complexity) decomposing complex logic into smaller, single-
purpose functions that are easily composed.

Apply the "Don't Repeat Yourself" (DRY) principle,

3. Adhere to the
as duplication is detrimental to software quality.
DRY Principle (No
Refactor redundant logic into reusable, single-
Duplication)
purpose functions.

Select, define, and adhere rigorously to software

4. Define and
coding methods, standards, and criteria (SWE-
Adhere to Coding
061). This ensures code quality and conformity
Standards
across the project.

A good design practice is to separate the

interface from the implementation (SWE-057
5. Separate Note), allowing for the substitution of variable
Interface from implementations through a common interface. FP
Implementation Context: Define function signatures explicitly and
clearly, treating the implementation as a hidden
detail.

The software design must be implemented

6. Implement
accurately into software code (SWE-060).
Design into Code
Crucially, confirm that the code does not contain
(No Unspecified
functionality not defined in the design or
Functionality)
requirements.

Continuously improve the structure and quality of

7. Practice the code without changing its external
Continuous Code functionality. This ongoing maintenance helps
Refactoring mitigate technical debt and improves long-term
quality.

II. Safety, Criticality, and State Management

If the Python scripts handle critical game logic (e.g., resource persistence, crucial
entity behavior, or interaction with external systems), these NASA safety
standards apply (SWE-134). FP minimizes the risk associated with mutable state,
supporting these objectives.

Best Practices Functional Programming NASA 2

 Practice Description & FP Context Source Citation

8. Initialize to a The software must be initialized, at first start and

Known Safe State restarts, to a known safe state (SWE-134a).

9. Ensure Safe The software must safely transition between all

State Transitions predefined known states (SWE-134b).

All functions (GN&C and general) shall implement

10. Ensure deterministic behavior in the presence of
Deterministic detectable numerical errors. FP Context: Pure
Behavior functions inherently promote determinism, which is
vital for verifiable, safety-critical operations.

11. Prevent Single Ensure that no single software event or action is

Event Hazards allowed to initiate an identified hazard (SWE-134i).

Implement mechanisms to detect inadvertent

12. Detect Memory memory modification (SWE-134f). FP Context:
Modification Minimizing reliance on mutable state significantly
reduces the likelihood of this class of errors.

13. Explicit
Termination of functions performed by software is
Termination to
executed to a known safe state (SWE-134c).
Safe State

III. Robustness, Error Handling, and Secure Code

These practices focus on fault prevention and fault tolerance, recognizing that
software is much more likely to fail by producing erroneous output than by failing
silently. They are derived from the Secure Software Development Framework
(SSDF: PW.5) and NASA Fault Prevention guidance.

Practice Description & FP Context Source Citation

Validate all inputs, and validate and properly

14. Validate Inputs
encode all outputs (PW.5.1 Example 1). This
and Encode
prevents external data from causing unintended
Outputs
behavior, a fundamental secure coding practice.

15. Provide Explicit The software must provide explicit error handling
Error Handling (SWE-134k) and detect errors and handle them
gracefully. FP Context: Use explicit error types
(e.g., Result or Either patterns) to manage

Best Practices Functional Programming NASA 3

 Practice Description & FP Context Source Citation
failures, allowing the system to recover to a known
safe state.

16. Avoid Unsafe Secure coding practices dictate avoiding the use
Functions and Calls of unsafe functions and calls (PW.5.1 Example 2).

Employ logic for handling off-nominal sensor and

17. Handle Off- data input, including anticipating and responding
Nominal Inputs to exceptions. Design for robustness against
unpredictable or invalid input.

18. Perform The software must perform integrity checks on

Input/Output inputs and outputs to/from the software system
Integrity Checks (SWE-134g).

The software should reject commands received

19. Reject Out-of- out of sequence when execution of those
Sequence Logic commands out of sequence can cause a hazard
(SWE-134e).

Configure software to have secure settings by

default (PW.9). Minimize the likelihood of being
20. Configure
deployed with weak security settings. Document
Secure Defaults
each setting's purpose, security relevance, and
default value.

21. Design for Keep the software design as simple as possible by

Minimal Inter- minimizing the number of calls between
Component Calls components.

IV. Verification, Testing, and Toolchain Rigor

Testing activities verify that the resulting code accurately implements the design
(SWE-060, SWE-066). For scripting, this rigorous analysis is applied directly to
the implemented code.

Practice Description & FP Context Source Citation

22. Unit Test All Unit test the software code (SWE-062). For critical
Software Code functions, confirm successful execution.

23. Assure Test Assure that the unit test results are repeatable
Repeatability (SWE-186). FP Context: This is straightforward

Best Practices Functional Programming NASA 4

 Practice Description & FP Context Source Citation
with pure functions, which guarantee the same
output for the same input.

For safety-critical software components, ensure

100 percent code test coverage using the
24. Achieve MC/DC
Modified Condition/Decision Coverage (MC/DC)
Coverage (Critical
criterion (SWE-219). MC/DC requires proving that
Code)
each condition independently affects the decision
outcome.

Use static analysis tools to analyze the code

(SWE-135) to, at a minimum, detect defects,
25. Use Static
software security issues, code coverage, and
Analysis Tools
complexity. Verify the code meets secure coding
standards using these results (SWE-185).

Plan and conduct software regression testing

(SWE-191) to demonstrate that defects/security
26. Conduct vulnerabilities have not been introduced into
Regression Testing previously tested software. Incorporate tests for
previously reported vulnerabilities into the test
suite.

Include tests to confirm software behaves in an

27. Test
expected manner under adverse or off-nominal
Adverse/Off-
conditions. This must cover boundary conditions,
Nominal Conditions
false/invalid inputs, load tests, and stress tests.

Perform peer reviews or inspections on software

28. Utilize Peer code (SWE-087), particularly for safety-critical
Reviews on Critical code, complex functions, or critical functions.
Code Have expert reviewers check code for backdoors
or malicious content.

Use up-to-date versions of interpreter and build

29. Configure
tools, and implement secure configurations to
Interpreter/Build
improve executable security (PW.6). Continuously
Tools Securely
verify the authenticity and integrity of these tools.

Track and manage defects found during testing to

30. Track Defects to closure. After identifying defects/vulnerabilities,
Root Cause analyze them to determine their root causes
(RV.3.1).

Best Practices Functional Programming NASA 5