They have this famous one - http://spinroot.com/gerard/pdf/P10.pdf
(https://dev.to/xowap/10-rules-to-code-like-nasa-applied-to-i...)
> Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition
> ... Because assertions are side-effect free, they can be selectively disabled after testing in performance-critical code.
Why would you put in recovery logic in if you're just going to disable it?
For example, let's say that I've got a new algorithm for calculating the cosine. Just to be safe, I add an assertion that the return value is in [-1, 1], and return an error if it isn't.
Now the clients of my code (say, the guidance computer) deal with the error somehow: if cos(x) returns an error, show an error to the pilot and maintain course or something.
If that assertion were stripped out in production code, then there was no point in writing the recovery logic. I've never written safety-critical code - am I missing something?
There are also many time critical code paths where microseconds matter.
Think of assertions in lots of places more like unit tests, important to verify your code but unhelpful in production.
Failure recovery can be whole entire systems for production which are much different than assertions.
I believe the idea here is that, if you've tested your code correctly, the assertions are never triggered and therefore your constraints are met and you don't need the checks anymore.
Somewhat interestingly, the Chromium code base does something similar. There are `DCHECK` macros everywhere that are assertions that crash if the condition is false (for instance if a variable is null or some such) but they're disabled in production builds
Of course nothing in space, keeping astronauts alive, should be using the web.
In such scenarios you can only kill the process - there’s no way to recover from such an error and handling it in any way but by disabling the subsystem (or killing the process) is impractical.
>performance-critical code.
These rules are for guaranteed-response-time algorithms that take data from a fixed number of places, do computations on it using fixed-size buffers, and write the data to a fixed number of places. They aren't for writing general Turing-complete computations in all their variety.