NASA（NASA，以下简称英文）有自己的一套编码标准，以确保所有NASA应用程序的代码质量和安全性。这些标准逐渐演变为适用于广泛的软件开发行业。代码安全规则JPL（喷气推进实验室）的资深科学家GerardJ.Holzmann表示，即使是关键应用程序的代码质量也受到大量任意规则和不一致准则的影响。这就是为什么该实验室发布了代码十诫命来管理所有NASA软件的原因。Holzmann和他的团队在设计这些软件开发规则时考虑到了代码安全性。该规则明确针对C语言编写-NASA用于备份安全关键代码的主要语言，具有悠久的历史和广泛的工具支持。然而，这些也适用于大多数其他编程语言：将所有代码限制为简单的控制流结构——没有goto语句、setjmp和longjmp结构，以及直接或间接递归。所有循环都必须有固定的上限。在数学上可以使用检查工具静态地证明预定的上限是循环不能超过的迭代次数。如果不能静态证明循环极限，则违反此规则。初始化后不要使用动态内存分配。标准引用格式的函数——每条语句一行，每条声明一行——必须放在同一页上。通常，这意味着每个函数的代码行不超过60行左右。代码的断言密度应该平均每个函数至少有两个断言。断言用于检查在实际实施中永远不会发生的异常情况。断言必须始终没有副作用，并且被定义为布尔测试。如果断言失败，则应采取显式恢复操作，例如，通过向执行失败断言的函数的调用者返回错误条件。对于任何断言，静态检查工具可以证明它永远不会失败或永远不会违反此规则（即，不可能通过添加无用的“assert(true)”语句来满足此规则）。另请参阅：《Developing NASA’s mission software with Java》数据对象必须在尽可能小的范围内声明。非空函数的返回值必须由每个调用函数检查，并且必须在每个函数内部检查参数的有效性。预处理器的使用必须限于包括头文件和简单的宏定义。不允许使用标记粘贴、变量参数列表和递归宏调用。所有宏都必须扩展为完整的句法单元。条件编译指令的使用也经常是狡猾的，但不能总是避免。这意味着我们不应超出标准样板，即使在大型软件开发中，条件编译指令也不应超过一两个，并避免多次包含相同的头文件。条件编译指令的每次使用都应在代码中由基于工具的检查器进行证明和标记。应限制指针的使用。具体来说，不允许超过一级的取消引用。指针解引用操作不能隐藏在宏定义或定义类型声明中。函数指针是不允许的。从开发的第一天起，所有代码都必须编译，所有编译器警告都应该以最严格的编译器设置打开。所有代码都必须在没有任何警告的情况下使用这些设置进行编译。所有代码每天至少要经过一台静态源代码分析器检查，当然也可以不止一台，零警告通过分析。***，正如Holzmann所解释的：如果你认为这些规则似乎过于严格，那么请不要忘记这是NASA，你的生活可能取决于它的正确性：代码用于控制你飞行的飞机，核能可能离你住的地方只有几英里，或者载着宇航员进入轨道的航天器。这些规则是这个行业需要的数字安全带——毕竟生命重于泰山，否则会带来浩劫……译文链接：http://www.codeceo.com/article/nasa-10-coding-commandments.html英文原文：NASA的十大编码命令欢迎发表你的看法。
