NASA’s 10 rules for developing safety-critical code

sdtimes.com

15 points·ColinWright··5 comments

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.

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...);

clang -Weverything -Werror

Buzz Lightyear voice: Errors! Errors everywhere!

Interesting to compare and contrast against previous JPL coding standards.

http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

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

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.

Reply on news.ycombinator.com