
NASA’s 10 rules for developing safety-critical code - ColinWright
http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/
======
hermitdev
These are great guidelines, but this is the second time today I've read
compile with the highest warning level possible, and treat all warnings as
errors. This is certainly laudable, but not always possible (I try to in my
own code to the greatest extent that I can). Some warnings are more
informational than an actual issue. For instance, MSVC warns about functions
marked inline that weren't inlined. Do I care? Depends on the situation, but
its enabled at W4.

~~~
Gibbon1
I sort of worry a little bit that the guidelines are too strict for everyday
code.

goto's are useful for error escape paths. I've seen rather convoluted control
flow done where breaking down and using a couple of goto's would make things
clean and understandable.

Function pointers are immensely useful.

Variadic macros are useful for implementing optional debugging statements. As
in PRINTF(format, args...);

------
cbanek
Interesting to compare and contrast against previous JPL coding standards.

[http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf](http://lars-
lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf)

My favorite rule is #14, check the return codes of functions.

------
habitue
this was hilarious when they got to how to apply the rules to javascript and
half of them don't apply because they're about memory management.

