
Rules for Developing Safety-Critical Code (2006) [pdf] - trymas
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
======
Symmetry
Mostly good rules for C development in these situations but see John Carmack
for a disagreement about rule 6.

[http://number-
none.com/blow/john_carmack_on_inlined_code.htm...](http://number-
none.com/blow/john_carmack_on_inlined_code.html)

~~~
snagglegaggle
Interesting to note that the description of how the flags and main loop works
in practice makes the resulting program close to ladder logic,[0] still used
in programming PLCs. Having used it the global state is annoying at first but
does make the program easy to reason about.

The ladders inputs and outputs almost become like a set of invariants like you
would find in a functional program, but the monad for state is implicit.

[0]
[https://en.wikipedia.org/wiki/Ladder_logic](https://en.wikipedia.org/wiki/Ladder_logic)

------
_iyig
I'll add another rule: don't ship behavior you can't test. This includes the
behavior of a stateful system after an extended period of uptime.

I once spent weekends and late nights fixing a bug which, if it had shipped,
would have eventually bricked an embedded product. It caused the software to
hang in a way which evaded every watchdog and reset timer. This bug was only
_barely_ caught by the edge of a multi-week stress test. As it turned out, the
bug itself wasn't in any of the code I had written, but in an open-source
dependency.

There are several ways to approach this problem. Besides simply testing your
product over an extended period of time, you can build a test harness which
simulates time at an accelerated rate. Another method is to periodically
reboot your system from scratch after the longest period of uptime you're able
or willing to test. It also helps to use software and hardware watchdogs which
automatically reset your system, in whole or in part, if it becomes
unresponsive (fails to "feed" the watchdog).

However, watchdogs by themselves aren't foolproof - in my case, the program's
main I/O loop kept running, but a critical part of the stack no longer
functioned correctly.

------
dang
Two threads from 2016:

[https://news.ycombinator.com/item?id=12092107](https://news.ycombinator.com/item?id=12092107)

[https://news.ycombinator.com/item?id=11890685](https://news.ycombinator.com/item?id=11890685)

And two from 2015:

[https://news.ycombinator.com/item?id=8898299](https://news.ycombinator.com/item?id=8898299)

2015:
[https://news.ycombinator.com/item?id=8856226](https://news.ycombinator.com/item?id=8856226)

------
evolve2k
> No function should be longer than what can be printed on a single sheet of
> paper in a standard reference format with one line per statement and one
> line per declaration. Typically, this means no more than about 60 lines of
> code per function.

Maybe it’s because C is a lower level language but for me these limits seem
much looser than is discussed in higher order languages, specifically for me
ruby.

Take Sandi Metz rules for practical object oriented [quality] code.

[https://thoughtbot.com/blog/sandi-metz-rules-for-
developers](https://thoughtbot.com/blog/sandi-metz-rules-for-developers)

1\. Classes can be no longer than one hundred lines of code. 2\.
Methods(functions) can be no longer than five lines of code.

Its a long way from a 5 line constraint to a 60 line constraint.

I agree with Sandi that smaller ‘single purpose’ functions lead to less
coupled, easier to maintain code.

Is 60 down to 5 lines just about a progression of thought, with 60 lines being
more what used to be acceptable and is possibly still acceptable with ‘older
languages’?

Is one better than the other? How to explain the difference?

~~~
autumnal
A 5-line constraint seems ridiculous to me, even in Ruby, and I imagine that
just about every codebase ever breaks it. Do you have an example project
following such a style?

~~~
pulisse
In Ruby, Rails and many projects in the Rails ecosystem aspire to it. The
result is (to me) poor code locality and unreadably deep call stacks.

~~~
anon1m0us
I can't imagine ever choosing RoR for a safety critical system.

------
BeetleB
This is from JPL.

For cars, there is an ISO standard for SW - and the rules are likely a lot
stricter than these. I wonder - will there ever be an ISO standard for space
travel?

~~~
nickpsecurity
You're thinking of MISRA C:

[https://en.m.wikipedia.org/wiki/MISRA_C](https://en.m.wikipedia.org/wiki/MISRA_C)

~~~
BeetleB
No. While MISRA C was created for cars, the ISO standard is ISO 26262. MISRA C
is not required for ISO 26262, but it does satisfy some of its requirements
and so most C developers will use it.

~~~
Glawen
Iso 26262 do not quote misra, but everything which it asks is basically
contained in misra

~~~
BeetleB
> Iso 26262 do not quote misra

It doesn't _require_ MISRA, but it does actually mention it as an example.

------
magwas
The most important rule is not there: All zombies should be thoroughly
justified: why a unit test cannot be written to kill it?

~~~
AnimalMuppet
Could you clarify what you mean here?

~~~
magwas
The test coverage should be so good that mutation testing finds nothing
uncovered.

