[Farmadupe]

just a few drive-by comments:

First and most important, the title claims these are safety-critical rules, but the conclusion says that they are only being used on mission-critical projects. I get the feeling that there might have been some late-change copyediting done here, as the content is far too generalizing to be taken seriously in any specific safety critical context, and hopefully the author would have known that.

* Agree that many safety-critical coding standards are a grab-bag of sometimes dubiously-valuable rules.

* Agree with the implication that stylistic guidelines are almost totally worthless, and may distract reviews from their core task of finding functional errors.

* The document states that manual review of large cases may be infeasible, but I have never worked on a project that didn't mandate it. Drudgery goes hand-in-hand with safety-critical, and mindnumbing close review is an accepted element of this.

* Agree that less rules is good, but the author doesn't justify why 10 rules is the best. Unfortunately this is a field where correctness trumps easiness or simplicity, and any class of error with unacceptable risk to life/limb must be prevented. Thus any ruleset cannot justify itself simply because it is small.

* In fact, there are many wordings in this document that are generally-unacceptable because they are admitting incompleteness in the general case (and therefore unsuitability for any safety-critical purpose), such as "Although such a small set of rules cannot be all-encompassing" or "In return, it should be possible to demonstrate more convincingly that critical software will work as intended"

commentaries on specific rules:

* rule 4: "No function should be longer than what can be printed on a single sheet of paper". In my experience, readability is not always improved by limiting function length. The main goal of safety-critical be correct (and hopefully be obviously so). Sometimes splitting up code is harmful to this. (also this is actually a stylistic rule of the kind rejected in the 2nd paragraph of the document.)

* rule 5: In the safety-critical domain, defensive checks and "assertions" are usually considered at low-level-design. It's generally unacceptable for a coder to "just" insert defensive behaviours into the implementation, because all such behaviours must be analyzed for correctness. I don't disagree with the idea behind this rules, but a coding standard is the wrong place for it.

[nunuvit]

> Agree that many safety-critical coding standards are a grab-bag of sometimes dubiously-valuable rules.

What frustrates me is that most standards are self-aware of this and explicitly allow you to tailor them, but hardly anyone does that to a meaningful extent.

[munch117]

Do that and you are just creating targets for the next security auditor that you need any sort of certification or approval from.

In the end you'll choose the path of least resistance, which is to slavishly obey every rule on the checklist. It's not that people don't want to tailor the rules. They try at first, and then it gets beaten out of them.

Frustrating indeed.