<story><title>The Power of Ten – Rules for Developing Safety Critical Code</title><url>http://spinroot.com/gerard/pdf/P10.pdf</url></story><parent_chain></parent_chain><comment><author>vog</author><text>This is an all-time classic.&lt;p&gt;Too bad that the article doesn&amp;#x27;t mention the original paper:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;pixelscommander.com&amp;#x2F;wp-content&amp;#x2F;uploads&amp;#x2F;2014&amp;#x2F;12&amp;#x2F;P10.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;pixelscommander.com&amp;#x2F;wp-content&amp;#x2F;uploads&amp;#x2F;2014&amp;#x2F;12&amp;#x2F;P10.pd...&lt;/a&gt;&lt;p&gt;Some interesting HN discussions around applying these NASA coding standards to JavaScript:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=8856226&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=8856226&lt;/a&gt;</text></comment>
<story><title>The Power of Ten – Rules for Developing Safety Critical Code</title><url>http://spinroot.com/gerard/pdf/P10.pdf</url></story><parent_chain></parent_chain><comment><author>garethrees</author><text>It looks to me as though the recommendation that RankRed has titled &amp;quot;Rule No. 5 — Low Assertion Density&amp;quot; would be better described as &amp;quot;High Assertion Density&amp;quot; — the recommendation is for a &lt;i&gt;minimum&lt;/i&gt; of two assertions per function (and functions are supposed to be short per rule 4).&lt;p&gt;The recommendations look good to me and (with one caveat) correspond to rules that I apply when writing C code with a high reliability requirement.&lt;p&gt;My one caveat is in &amp;quot;Rule No. 8 – Limited Use of Preprocessor&amp;quot; which bans all complex uses of the preprocessor. The problem is that it is common in C to encounter situations where the only way to avoid lots of code duplication is to store a table of facts in a macro definition and use the preprocessor to expand those facts into the relevant bits of code in each place where they are used. So in these situations you face a trade-off between the risks due to complex preprocessor use, and the risks due to code duplication (namely, a maintainer might change a fact in one place where it is used but fail to change it in another). My experience is that the risks due to code duplication are very high, and so it&amp;#x27;s worth the risk of using complex preprocessor macros to avoid them. The risks can be mitigated by implementing the necessary macros in a structured way to keep the complexity under control: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;garethrees.org&amp;#x2F;2007&amp;#x2F;04&amp;#x2F;24&amp;#x2F;relational-macros&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;garethrees.org&amp;#x2F;2007&amp;#x2F;04&amp;#x2F;24&amp;#x2F;relational-macros&amp;#x2F;&lt;/a&gt;</text></comment>