NASA has a list of 10 rules for software development

Read the original and it explains the purpose of each item:<p><a href="https:&#x2F;&#x2F;spinroot.com&#x2F;gerard&#x2F;pdf&#x2F;P10.pdf" rel="nofollow">https:&#x2F;&#x2F;spinroot.com&#x2F;gerard&#x2F;pdf&#x2F;P10.pdf</a><p>The original clearly describes that the coding rules primarily target C and attempt to optimize the ability to more thoroughly check the reliability of critical applications written in C. The original author clearly understands what they&#x27;re doing, and explains lots of other ways to verify C code.<p>For what it&#x27;s worth, the rationales in the original all make perfect sense to me. Perhaps this is because I learned C on tiny systems? I learned C for hardware for implanted medical devices, and our lab did similar kinds of guidelines.

The final paragraph is brilliant:<p><pre><code> &gt; If the rules seem Draconian at first, bear in mind that they are meant to make it possible to check code where very literally your life may depend on its correctness: code that is used to control the airplane that you fly on, the nuclear power plant a few miles from where you live, or the spacecraft that carries astronauts into orbit. The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable.</code></pre>

If I made my own criticism of these rules it would be very different from OP. It was difficult to take the article serious from the get-go when it defended setjmp&#x2F;longjump. That pattern is so obviously broken from anyone who has ever had to go near it. The article makes an argument like this:<p>1. setjmp&#x2F;longjmp is exception handling<p>2. exception handling is good<p>and I take serious issue with that second premise.<p>Also the loop thing obviously means to put a max iteration count on every loop like this:<p>for (0..N) |_| {<p>}<p>where N is a statically determined max iteration count. The 10^90 thing is silly and irrelevant. I didn&#x27;t read the article past this point.<p>If I were to criticize those rules, I&#x27;d focus on these points:<p>* function body length does not correlate to simplicity of understanding, or if anything it correlates in the opposite way the rules imply<p>* 2 assertions is completely arbitrary, it should assert everything assertable, and sometimes there won&#x27;t be 2 assertable things

&gt; People using Ada, Pascal (Delphi), JavaScript, or functional languages should also declare types and functions as locally as possible.<p>My own personal approach in JavaScript is to avoid defining functions in a nested manner unless I explicitly want to capture a value from the enclosing scope.<p>This is probably due to an outdated mental model I had where it was shown in performance profiling that a function would be redefined every time the enclosing function was called. I doubt this is how any reasonable modern JavaScript interpreter works although I haven&#x27;t kept up. Since the introduction of arrow functions (a long time ago now in relative terms) their prolific use has probably lead to deep optimizations that render this old mental model completely useless.<p>But old habits dies hard I guess and now I keep any named function that does not capture local variables at a file&#x2F;module scope.<p>A lot of the other notes are interesting and very nit-picky in the &quot;technically correct is the best kind of correct&quot; way that older engineers eat up. I feel the general tone of carefulness that the NASA rules is trying to communicate to be very good and I would support most of them in the context that they are enforced.

Just for context, these aren’t really “rules” as much as proposed practices. Note that official “rules” are in documents with names like “NPR” aka “NASA procedural requirements.”[1] So, while someone may use the document in the featured article to frame a discussion, a developer is not bound to comply (or alternatively waive) those “rules” and could conceivably just dismiss them.<p>[1] e.g. <a href="https:&#x2F;&#x2F;nodis3.gsfc.nasa.gov&#x2F;displayDir.cfm?t=NPR&amp;c=7150&amp;s=2D" rel="nofollow">https:&#x2F;&#x2F;nodis3.gsfc.nasa.gov&#x2F;displayDir.cfm?t=NPR&amp;c=7150&amp;s=2...</a>

The rule about recursion is likely also to ensure a statically known bound on needed stack space, in addition to a statically known runtime bound (in conjunction with the other rules).<p>While the criticism of rule 3 is right in that there is a dependence on the compiler, it is still a prerequisite for deriving upper bounds for the runtime by static analysis on the binary. This is actually something that is done for safety-critical systems that require a guaranteed response time, based on the known timing characteristics of the targeted microprocessor.

&gt; Since programmers these days typically read their code on-screen, not on paper, it&#x27;s not clear why the size of a sheet of paper is relevant any longer.<p>Folks spent a while (centuries?) iterating on the standard page and character sizes. It makes sense to me that what we landed on wasn’t solely due to the limitations of paper, but also the limitations of humans.

Title should indicate that this is a _criticism_ of the rules.

Someone in NASA once told me that it was easier to teach a mechanical engineer to program then a software developer mechanical engineering.<p>From that perspective, the avoidance of recursion is more compelling. Plus, Fortran didn&#x27;t support it...

GCC, at least, allows you to get stack usage (after compilation), and caller-callee relationships (-fstack-usage, -fcallgraph-info, etc). From this one can infer maximum stack size. It will not work with recursion or function pointers, unless one manually incorporated additional data.<p>setjmp() and longjmp(), are a poor way of handling exceptions, as any cleanup code won&#x27;t be executed. Of course, following the spirit of these rules, one would not have resources that need cleaning up but still.<p>The main issue, that is never mentioned, because it will be different in each application, is what to do when something goes wrong. Say an iteration limit is exceeded, or the fixed resources allocated at startup are not enough.

Nothing special as those are like MISRA C rules from automotive industry.<p>I see that is repackaging of low level rules and not some „magical 10 development rules” that would apply to your yet another CRUD app.<p>Not to bash article just informing people who would write „software engineering is not real engineering” - it is real engineering and there are norms. Just because someone did not hear about standards and rules and practices doesn’t mean there are none.

I work with a lot of embedded and embedded-adjacent software, and even I think several of these rules are too much. Having said that, Holzmann&#x27;s rules are from 2006, and embedded &#x2F; space qualified hardware has improved quite a bit since then. These days planetary probes run C++, and JWST even uses JavaScript to run command scripts. Things are changing.

&gt; All loops must have a fixed upper-bound<p>Things like spinlocks or CAS (Compare-And-Swap) are elegant and safe solutions for concurrency, and AFAIK you can’t really limit their upper bound. Others in the thread have pointed out that those are more guidelines than rules - still, not sure about this one.

They write the right stuff:<p>- <a href="https:&#x2F;&#x2F;www.fastcompany.com&#x2F;28121&#x2F;they-write-right-stuff" rel="nofollow">https:&#x2F;&#x2F;www.fastcompany.com&#x2F;28121&#x2F;they-write-right-stuff</a> (pdf: <a href="https:&#x2F;&#x2F;www.eng.auburn.edu&#x2F;~kchang&#x2F;comp6710&#x2F;readings&#x2F;They%20Write%20the%20Right%20Stuff.pdf" rel="nofollow">https:&#x2F;&#x2F;www.eng.auburn.edu&#x2F;~kchang&#x2F;comp6710&#x2F;readings&#x2F;They%20...</a>)

It seems they also need.<p>11. Use strict typing for all scalar types. Do not mix imperial and metric units.

The physical constraints of a sheet of paper are pleasing to the eye. Otherwise the dimensions of paper would be different. Oh well, it was good for a chuckle.

This is written with a weird attitude of trying to find problems with the rules. Take this for example:<p>&gt; This does a bounded number of iterations. The bound is N^10. In this case, that&#x27;s 10^90. If each iteration of the loop body takes 1 nsec, that&#x27;s 10^81 seconds, or about 7.9×10^72 years. What is the practical difference between “will stop in 7,900,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years” and “will never stop”?<p>... yes, you&#x27;re very smart and have found a way to technically satisfy the requirement while building a broken program<p>Clearly the upper bound rule is to make it easy to reason about worst-cases so setting a very high one isn&#x27;t really the gotcha they seem to think it is. It just means you can look at the high bound and go &quot;this is too high, fix it&quot;

I don&#x27;t like the &quot;I criticize you for not having my use case&quot; attitude.

I think some of these recommendations, while overall excellent, are somewhat self-contradictory. For example, functions that are no longer than one screenful, AND ban on function pointers, AND the general rule to keep the codebase readable.<p>How do you implement a state machine, like a byte code interpreter? You need some way to dispatch functions based on opcodes. You could argue it has no place in mission-critical code, but well-understood, time-bound state machines (like Plan9-style regexes or BPF) can actually greatly increase code readability.<p>Also: Greenspun&#x27;s tenth rule.

<p><pre><code> int const N = 1000000000; for (x0 = 0; x0 != N; x0++) for (x1 = 0; x1 != N; x1++) ... for (x9 = 0; x9 != N; x9++) -- do something --; </code></pre> Rule 1 would disallow this. Probably other rules as well, depending on the details for your code analysis tools.<p>Also the article seems to imply the rule about recursion was about knowing your program would terminate, but the rationale from the rules says it&#x27;s about verifying execution is bounded. That&#x27;s a somewhat different concept. With recursive calls you have the stack to consider.

Friendly reminder that you are most likely not NASA and have different goals, so you should approach the problem differently. The cost of a stack overflow (even at FAANG-scale) for you is likely many orders of magnitude cheaper than for NASA, and the cost of delaying a project for a year is much worse.<p>Unless you work on commercial aircraft avionics. NASA flying a probe into Mars makes them look dumb. Flying an aircraft into a mountain haunts people for the rest of their lives.

Example 1 is a deficit of C with missing computed goto and switch continue. Example 2 review is ambiguous on practicality. Example 3 reads very odd, an over-approximated upper stack bound is very possible <a href="https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;issues&#x2F;157#issuecomment-763952294">https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;issues&#x2F;157#issuecomment-76395...</a> and tighter computation with advanced analysis as well. Example 4,5,6,7,8,9,10 yes. Overall good read.

These rules are obviously for something critical.<p>I don&#x27;t think they are saying that if you write some kind of service program at NASA, it cannot have an infinite loop for taking requests. Or if you write a line-by-line file processing utility, it has to cap out at a maximum number of lines so that the loop is statically bounded. Or that if you write some tool to process syntax, perhaps a compiler, that you cannot use recursion.<p>These are not embedded, safety-critical things.

Looking over the list I determined that I already regularly follow all the rules but the first three.<p>But, as a C#&#x2F;C++&#x2F;Typescript developer, I don&#x27;t have the first clue how any I might go about implementing those rules.<p>Anybody know of patterns for this kind of safe programming that I can use?<p>Does just using a language like Zig automatically make my code &#x27;safe&#x27;?<p>Anybody know if generating code from a proof checking language like Lean would satisfy all these rules?

nice, saved because these days who know ho long the page will be available :)

The first rule of writing safety-critical systems in C: Don&#x27;t write safety-critical systems in C.

Safer to put 50 interns each working on their own version of the code and the have it run 50 times in parallel and choose the answer that most of them agree to. No need for standards then. Probably also more robust to radiation bit flips.

Well, I was expecting to see:<p><i>Rule 1: Don&#x27;t write any code that can make the ship go ka-boom.</i><p><i>Rule 2: We need to consistently use the f&#x27;ing metric system and SI units - and don&#x27;t you forget it.</i><p><i>Rule 3: ... You haven&#x27;t already forgotten about rule #2, have you?</i>

Very C centric.<p>&gt; The assertion density of the code should average to a minimum of two assertions per function.<p>I would actually say the opposite in modern languages like Rust. Assertions are a sign you have failed to encode requirements in the type system.

Note this is NASA&#x2F;JPL, not NASA-wide, JPL is a NASA center (FFRDC).

This looks more like rules for C development. In order to make reliable software in C (which is honestly pretty brave to begin with once you get past a certain complexity treshold).

My ex-boss completed his PhD thesis with author of this doc as his advisor. So some of the ideas seem relevant since they popped up in few of the work related conversations with my boss.

Rule 11: Use metric for everything

This makes me love Go even more.<p>Gotta appreciate the things that the compiler takes care of for me.<p>While I wish the stop-the-world GC pause were more predictable and took less time, I’ll gladly pay the cost for safety.<p>Zig seems interesting, too. It feels like a better C, and I’m closely following its development as it marches toward 1.0.

No function pointers? That severely restricts the utility of the language…

fun fact, the same guy (G Holzman) also made the Spin model checker

from the original document: &quot;critical code is written in C.&quot; The document is not dated, but it&#x27;s probably quite old (I&#x27;m guessing 30-something years). Writing critical code in C is probably a mistake, but once you find yourself in that situation, you will find these rules are too tight (which is also what the criticism is about). You should probably read them as &quot;try to avoid ...&quot;.<p>So I would just prepend the document with &quot;Rule 0: Try to avoid writing critical code in C.&quot;

Good thing to give to LLMs as well.

Did I just go back 40 years in time?

&gt; Note that setjmp() and longjmp() are how C does exception handling, so this rule bans any use of exception handling.<p>In theory yeah, but I&#x27;ve very rarely encountered it in the wild.<p>It&#x27;s hard to use right in any code that has cleanup to do, without building a lot of infrastructure for resource handling.

No recursion means no Erlang. Which means no RabbitMQ?

now raise your hand if you are actually in the business of writing code being deployed on JPL missions .....<p>bueller? bueller???

I&#x27;m terrified - do they really use C at NASA? I thought it&#x27;s all ADA. In fact, most of the rules would be automatically satisfied by an early FORTRAN, as it had no heap, no stack and no recursion.