In my A Fatal C Error post I talked about how hard it is to write error-free C code. Any large C program is almost guaranteed to have undetected errors. That’s true of all languages—TeX is famous for being the only large programming system that approaches zero errors—but is especially true of C.
Nevertheless, NASA is renowned for writing nearly faultless mission critical software in C. The NASA software developers are so good at this that after the Challenger disaster, the famed physicist Richard Feynman compared the rest of NASA unfavorably to the software team.
That raises the question of how they achieved such excellence. As I mentioned in the Fatal C Error post, part of their secret was a comprehensive and strict set of coding standards. Here they are.
If you’re like me, your first reaction is probably, “But but but…they’ve outlawed all my favorite techniques.” Still, all those favorite techniques are exactly why writing correct C code is so difficult. NASA, of course, is writing software where millions (or billions?) of dollars, not to mention lives, are at stake so there’s little room for error.
The article at the link doesn’t talk about their development process but it is similarly rigorous. All code is gone over line-by-line by the development team and subjected to numerous tests and simulations. I don’t have a link to those at the moment but if I find them, I’ll write another post because the NASA software developers show how it is possible to write safe and efficient code.
Again, if you aren’t terrified when you read about the code running the car you use everyday, you aren’t paying attention.
Afterword
After I wrote this post, I discovered Astroguard, a code auditing and profiling tool that enforces NASA’s coding standards. Take a look at it if you’re interested in such things.