NASA 的 10 条代码编写原则

美国宇航局（National Aeronautics and Space Administration，缩写为 NASA）是美国联邦政府的一个独立机构，负责制定、实施美国的民用太空计划、与开展航空科学暨太空科学的研究。在太空计划之外，美国国家航空航天局还进行长期的民用以及军用航空航天研究。

在普通人的眼中，NASA 是一个很“高级”的机构，其成员包含大量不同领域的科学家和研究人员。与其他任何组织机构类似，NASA 的日常工作，以及所执行的几乎全部项目也离不开计算机的辅助，出于需求的特殊性和重要性，他们所使用的很多计算机软件都是内部自行开发的，在一些重要项目的关键领域发挥着作用。

去年，一位前 NASA 实习生把美国阿波罗登月项目的 11 号计算机 — 阿波罗导航计算机 (Apollo Guidance Computer) 系统源代码上传到了 GitHub ，此举在开发者群体中引起了极大的热议。

此外，NASA 官方也已将自己的部分源代码开源到 GitHub ，让我们得以管窥这一顶尖科研机构内的聪明大脑们写代码的专业水平。

大型的复杂软件项目通常会遵循一定的代码编写标准和指南。这些指南奠定了软件开发过程中必须遵守的基本原则。

a) 代码的结构如何安排？

b) 应当或不应当使用哪些语言特性？

出于效果的角度考虑，这些原则必须尽可能精简并且必须足够具体，这样才能更好地被人理解并记忆。

本文将介绍由 NASA 喷气推进实验室首席科学家 Gerard J. Holzmann 所提出的，侧重于安全参数的 10 条代码编写原则。当然，这些原则也适用于其他编程语言。

为 NASA 工作的全球顶尖程序员在编写高度安全的代码时就沿袭了这样的一套指南。实际上，很多组织，包括NASA 喷气推进实验室主要会选择使用C 语言编写代码。

原因在于这种语言具备完善的工具支持，包括逻辑模型分离器、调试器、静态编译器、强源（Strong source）代码分析器，以及度量工具等。

有时候，编写代码必须遵守一定的原则，尤其是在代码的正确性会对人的生命产生决定性影响的领域，例如飞机、将宇航员送上同步轨道的航天器，以及距离居住地仅几英里远的核电站等设施运行的控制代码。

原则 1 – 简化控制流程

使用尽可能精简的控制流程构造编写程序 – 不要使用setjmp或longjmp构造、goto语句，以及直接或间接的recursion。

原因：简化控制流程有助于提高代码清晰度，增强代码可验证能力。不使用递归，便不会产生循环的函数调用图，这样也可证明所有本应有界的执行实际上都是有界的。

原则 2 – 为循环使用固定次数上限

所有循环必须有固定次数的上限。我们可以通过验证工具静态地证明，为循环中迭代数量所设立的上限次数未被超越。

如果无法以静态方式对循环的次数界限加以证明，则可认为未遵守该原则。

原因：为循环设置次数界限，避免使用递归，这些做法有助于预防代码失控。然而该原则无法适用于本就不应终止的迭代（例如进程调度器）。此时将沿用该原则的逆向原则：必须能够静态地证明迭代不能终止。

原则 3 – 不使用动态内存分配

不要在初始化完成后进行动态内存分配。

原因：诸如malloc等内存分配机制，以及垃圾回收器通常会产生无法预知的行为，进而可能会对性能产生影响。更重要的是，还有可能因为程序员的失误造成内存错误，例如：

• 试图分配超过可用物理内存数的内存
• 忘记释放内存
• 继续使用已被释放的内存
• 对已分配内存进行越界使用

应强制所有模块位于固定大小、预先分配的存储区域中，借此可避免此类问题，并简化内存使用情况的验证工作。

堆中未分配内存的情况下，动态请求内存的唯一方式是使用栈内存。

原则 4 – 不使用冗长的函数

任何函数的长度不应超过使用标准参考格式（每个声明最多一行，每个语句最多一行）打印的纸张上一页纸所能容纳的字符数。这意味着函数的代码不应超过 60 行。

原因：过长的函数通常意味着结构并非最优。每个函数都应是可理解且可验证的单一逻辑单位。如果在计算机显示器上需要多屏界面才能完整显示，这样的逻辑单位通常会极难理解。

原则 5 – 低断言密度

程序的断言密度（Assertion density）应平均保持为每个函数最少两个断言。断言可用于检查现实运行过程中本绝不应出现的异常状况，因此应定义为 Boolean 测试。当断言失败后，应执行明确的恢复操作。

如果静态检查工具证明断言绝对不会 Fail 或 Hold，则可认为未遵守该原则。

原因：业界的代码编写工作统计报告显示，通过单元测试可发现，通常我们所编写的每 10-100 行代码中至少会存在一处缺陷。随着断言密度的增高，拦截缺陷的机会也会增大。

断言的另一个重要之处在于，它是防御性编程（Defensive coding）策略的重要组成部分。我们可以使用断言验证函数执行前后的状况，函数的执行参数和返回值，以及循环不变式（Loop-invariant）。在完成性能关键代码的测试工作后，可将断言选择性地禁用。

原则 6 – 以最小范围级别声明数据对象

该原则同时也是数据隐蔽（Data hiding）的基本原则。所有数据对象均必须以尽可能最小的范围级别进行声明。

原因：如果某对象不在范围内，意味着其值将无法引用或已损坏。该原则不鼓励出于多种可能导致故障诊断工作变得更复杂的互斥意图重用变量。

原则 7 – 检查参数和返回值

应在每次调用函数后检查非空函数的返回值，并应在每个函数内部检查参数的合法性。

在最严格的形式下，该原则意味着就算printf语句和文件close语句的返回值也应进行检查。

原因：如果对一个错误结果的响应与对成功结果的响应本不应有任何区别，那么很明显需要检查返回值。通常对close和printf的调用便符合这种情况。此时一种可行的方法是将函数的返回值明确抛出给void，这意味着开发者明确（而非意外地）决定忽略该返回值。

原则 8 – 限制预处理程序的使用

预处理程序（Preprocessor）应仅限用于头文件和宏定义。递归的宏调用、令牌传递，以及变量参数列表均不允许使用。就算大型应用程序开发工作中，标准样板文件（Boilerplate）之外也可能有必要使用一两个以上的条件编译指令，这是为了避免将同一个头文件包含多次。每个这种用法必须通过工具检查器添加标记，并通过代码阐述原因。

原因：C 语言预处理程序是一个强大但较为含糊的工具，有可能彻底破坏代码的清晰度，并让很多基于文本的检查器产生混淆。就算具备正式的语言定义，包含无界限预处理程序代码的构造也会显得非常难以解读。

有关条件编译的注意事项同样很重要 – 就算只使用 10 个条件编译指令，代码也有会产生 1024（2^10）个可能的版本，这会导致测试工作量剧增。

原则 9 – 限制指针的使用

指针的使用必须加以限制。通常只允许不超过一层的解引用（Dereferencing）。指针解引用操作不应隐藏在typedef声明或宏定义内部。此外函数指针也是不允许使用的。

原因：指针很容易被滥用，就算专家也难以彻底避免。指针的存在会使得我们难以跟踪或分析程序中数据的流动，尤其是在使用基于工具的静态分析器执行这些操作时。函数指针还会对静态分析器所能执行的检查类型产生限制，因此除非有非常必要的理由，否则一般不推荐使用。如果使用函数指针，通常几乎将无法通过工具证明递归的缺席，此时只能提供其他方法弥补这种分析能力的缺失。

原则 10 – 编译所有代码

从开发工作第一天开始时，就必须对所有代码进行编译。必须启用编译器的警告功能，并使用最细致的检查选项。代码必须能通过这样的设置在不产生任何警报的情况下顺利编译完成。

所有代码必须每天一次，使用至少一种（多种则更好）最新型的静态源代码分析器进行检查，并且必须顺利通过分析器的整个检查过程而不产生任何警告。

原因：市面上有很多效果卓越的源代码分析器，其中很多甚至是以免费软件的形式发布的。对于这样可以直接使用的现成技术，任何软件开发工作都没理由不加以充分利用。

如果编译器或静态分析器遇到问题，导致问题 / 错误的代码必须重写，这样才能进一步改善代码质量。

NASA 对这些原则的看法为：“这些原则就如同汽车安全带，也许一开始会觉得有些不舒适，但很快会变成每个人的第二本能，到时候很难想象会有人不这么做。”

此文在 Reddit 引发了热烈的讨论，现将部分有价值内容摘录如下：

本文的很多原则提到使用静态代码分析器进行分析是一种更简单可靠的办法。如果我在开发 C 或 C++ 代码，有什么好用的免费静态代码分析器吗？一方面我想看看这些分析器的工作效果，另一方面，我一直在使用另一个极为糟糕的分析器，想对比一下来了解原本使用的分析器到底有多糟糕。
@fluffynukeit

我觉得有必要提醒大家，本文所说的“安全关键程序”是一种面向特定领域的术语。每次网上流传类似这样的东西时，大家都会试图将相关内容应用在一般常规用途的软件中，但实际上除非你的软件中出现的无法处理的异常真的会致命，否则并不需要如此严格（也许也不应该这样做，因为大部分此类原则会在代码可读性和可维护性方面造成不小的麻烦）。
@tobascodagama

原则 3 – 不使用动态内存分配
这条让我大吃一惊。我很好奇，如果不使用动态内存分配，你到底如何编写哪怕很小规模的程序！是否就只在程序运行时分配一大块内存，随后程序的所有执行都在这块内存中进行？
@xianbaum

我倒是对于 NASA 使用 C 语言感觉惊讶，我本想着他们会使用 Ada 之类的东西。
这些原则中很多原则与我在 ASEA（现 ABB）担任开发者时所遵守的原则是相同的，抛开这些不谈，同时抛开有关预处理程序的原则不谈，我们当时主要使用 Pascal，对于递归函数也制订了相应的原则。我编写了一个预处理程序，这样就可以保证开发者能够获得恰当的声明，而无需担心这些问题，此外我们还会按照标准设置程序代码的缩进和格式，毕竟每个程序员在代码格式方面都有一些个人偏好。所有程序都有必要在这些问题方面由其他程序员进行交叉检查。
@aim2free

他们为什么不把这些原则强制应用到编译器中？可以通过 -WNasa 或其他类似的东西告诉开发者是否违反了这些原则。此外还需要使用 std lib C 来维护这些严格的原则。
建议挺好，就是不明白为什么不用自动化的方法来应用（或者他们正是这样做的?）
@NewYorkCityGent

作者：Gerard J. Holzmann，阅读英文原文： NASA’s 10 Coding Rules for Writing Safety Critical Program

感谢郭蕾对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。