美国航天局的十大编码戒律

美国航天局的十大编码戒律

Holzmann和团队在设计这些软件开发规则时，时刻谨记代码的安全问题。该规则明确写明是关于C语言的——C语言是NASA用于备份关键安全代码的支柱语言，有着悠久的历史和广泛的工具支持。不过，这些也可应用于其他大多数编程语言：

• 限制所有代码为简单的控制流结构——不使用goto语句，不使用setjmp和longjmp结构以及直接或间接的递归。
• 所有的循环必须有固定的上限。用检查工具静态地证明，预先设定的上限是一个循环不能超过的迭代次数，在数学上是可能的。如果循环限制不能静态证明，那么就违背了此条规则。
• 初始化后不要使用动态内存分配。
• 一个函数在标准参考格式下——每个语句一行，每个声明一行——得能印刷到同一张纸上。通常，这意味着每个函数的代码不超过60行左右。
• 代码的断言密度应平均为至少每个函数有两个断言。断言用于检查异常情况，在现实执行中是永远不会发生的。断言必须始终是无副作用的，并且被定义为布尔测试。如果断言失败，那就应该采取明确的恢复行动，例如，通过返回错误条件到执行失败断言的函数的调用者。对于任何断言，静态检查工具可以证明，它永远不会失败或从未违背此条规则（即，不可能通过增加无益的“assert(true)”语句来满足此条规则）。参见：《Developing NASA’s mission software with Java》
• 数据对象必须在尽可能小的范围内声明。
• 非空函数的返回值必须由每个调用函数进行检查，参数的有效性必须在每个函数内部进行检查。
• 使用预处理器必须仅限于包含头文件和简单宏定义。标记粘贴，变量参数列表，以及递归宏调用是不允许的。所有宏必须扩展到完整的语法单位。条件编译指令的使用通常也是靠不住的，但无法始终避免。这意味着，我们不应该超出标准样板，即使在大型软件开发中，也不应该有超过一个或两个条件编译指令，并避免多次包含相同的头文件。每一次使用条件编译指令都应该有正当理由，并在代码中通过基于工具的检查器标记。
• 指针的使用应当受到限制。具体地讲，解引用不允许超过一个级别。指针解引用操作可能无法隐藏在宏定义或内部定义类型声明。函数指针是不允许的。
• 从开发的第一天开始，所有代码都必须进行编译，并且所有的编译器警告应该在编译器最严谨的设置下开启。所有代码都必须在这些设置没有任何警告下进行编译。所有代码每日至少必须经过一台静态源代码分析器检查，当然最好能够不止一台，并在零警告下通过分析。

最后，正如Holzmann解释的那样：

如果你觉得这些规则看上去过于苛刻，那么请不要忘记，这是在NASA，你的生命可能就取决于它的正确性：代码要用来控制你飞的飞机，核能量与你住的地方可能只有几英里，或携带宇航员送入轨道的航天器。

这些规则正是这一行业所需的数字安全带——毕竟，生命之重重于泰山，否则将会带来一场浩劫……