safety-critical-patterns
Guidelines from the NASA Power of 10 rules for writing robust, verifiable code. Adapted for general software development with context-appropriate rigor. Use when writing critical code paths, reviewing for robustness, improving code quality. Do not use as rigid requirements for all code - match rigor
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 337
- Лиценз
- Не е посочен. Проверете в репозитория.
- Последна проверка на записа
- Няма посочена дата
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add athola/claude-night-marketСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
Safety-Critical Coding Patterns
Guidelines adapted from NASA's Power of 10 rules for safety-critical software.
When to Apply
Full rigor: Safety-critical systems, financial transactions, data integrity code Selective application: Business logic, API handlers, core algorithms Light touch: Scripts, prototypes, non-critical utilities
"Match rigor to consequence" - The real engineering principle
When NOT To Use
- Ordinary application code, where these defensive checks become the
bloat that
prefer-invariants-over-fallbackstargets (useconserve:code-quality-principles)
The 10 Rules (Adapted)
1. Restrict Control Flow
Avoid goto, setjmp/longjmp, and limit recursion.
Why: Ensures acyclic call graphs that tools can verify. Adaptation: Recursion acceptable with provable termination (tail recursion, bounded depth).
2. Fixed Loop Bounds
All loops should have verifiable upper bounds.
# Good - bound is clear
for i in range(min(len(items), MAX_ITEMS)):
process(item)
# Risky - unbounded
while not_done: # When does this end?
process_next()
Adaptation: Document expected bounds; add safety limits on potentially unbounded loops.
3. No Dynamic Memory After Initialization
Avoid heap allocation in critical paths after startup.
Why: Prevents allocation failures at runtime. Adaptation: Pre-allocate pools; use object reuse patterns in hot paths.
4. Function Length ~60 Lines
Functions should fit on one screen/page.
Why: Cognitive limits on comprehension remain valid. Adaptation: Flexible for declarative code; strict for complex logic.
5. Assertion Density
Include defensive assertions documenting expectations.
def transfer_funds(from_acct, to_acct, amount):
assert from_acct != to_acct, "Cannot transfer to same account"
assert amount > 0, "Transfer amount must be positive"
assert from_acct.balance >= amount, "Insufficient funds"
# ... implementation
Adaptation: Focus on boundary conditions and invariants, not arbitrary quotas.
6. Minimal Variable Scope
Declare variables at narrowest possible scope.
# Good - scoped tightly
for item in items:
total = calculate(item) # Only exists in loop
results.append(total)
# Avoid - unnecessarily broad
total = 0 # Why is this outside?
for item in items:
total = calculate(item)
results.append(total)