美国国家航空航天局（National Aeronautics and Space Administration，缩写为NASA）是美国联邦政府的一个独立机构。 负责制定、实施美国的太空计划，开展航空科学暨太空科学的研究。
作为一家厉害到分分钟“上天”的国字头机构，这里自然聚集了全球顶尖的科学家、工程师、设计师，以及码农。
他们写的代码能上天
在凶险的太空环境里，人类的足迹十分有限，为了不断向更远处进发，NASA的许多工作都离不开计算机的辅助。而且，因为需求的特殊性和重要性，他们所使用的很多计算机软件都是内部自行开发的，码农地位之高，不言自喻。
图片来源：pixelscommander
著名的喷气推进实验室 （Jet Propulsion Laboratory ，缩写JPL） 为 NASA 做了大量此方面的研究和开发。比如著名的“ 好奇号 ”火星探测器、“旅行者号”探测器，后者在飞行25年后离开了太阳系，至今仍为地球提供着科学信息。
图片来源：sdtimes
“地面上”的码农出现bug可能会导致黑屏，这里的码农如果出现bug那很可能会引发一场牵连性命的事故，这样高水平自动化的长时间任务，对软件质量提出了更高的要求。
当代码的正确性会对人的生命产生决定性影响的时候，例如飞机、将宇航员送上同步轨道的航天器、以及距离居住地仅几英里远的核电站等设施运行的控制代码，编码的标准自然也就提高了许多许多倍。
编程界的“航天标准”
在美国加州理工学院喷气推进实验室与美国国家航空航天局 的 共同研究下，NASA 喷气推进实验室首席科学家 Gerard J. Holzmann 提出了 侧重于安全参数的10条代码编写准则，指导着为 NASA 工作的全球顶尖程序员编写高度安全的软件代码。
图片来源：rankred
这些指南奠定了软件开发过程中必须遵守的基本原则：
1、代码的结构如何安排？
2、应当或不应当使用哪些语言特性？
出于效果的角度考虑，这些原则必须尽可能精简并且足够具体，这样才能更好地被人理解、记忆。
10条安全编码准则
1、简化控制流程
使用尽可能精简的控制流程构造编写程序，不要使用 setjmp、 longjmp 构造和 goto 语句，以及直接或间接的 recursion。
┇ 原因： 简化控制流程有助于提高代码清晰度，增强代码可验证能力。不使用递归，便不会产生循环的函数调用图，这样也可证明所有本应有界的执行实际上都是有界的。
━━━━━
2、为循环使用固定次数上限
所有循环必须有固定次数的上限，我们可以通过验证工具静态地证明，为循环中迭代数量所设立的上限次数未被超越。
如果无法以静态方式对循环的次数界限加以证明，则可认为未遵守该原则。
┇ 原因： 为循环设置次数界限，避免使用递归，这些做法有助于预防代码失控。然而该原则无法适用于本就不应终止的迭代 （例如进程调度器） 。此时将沿用该原则的逆向原则：必须能够静态地证明迭代不能终止。
━━━━━
3、不使用动态内存分配
不要在初始化完成后进行动态内存分配。
┇ 原因： 为诸如 malloc 等内存分配机制，以及垃圾回收器通常会产生无法预知的行为，进而可能会对性能产生影响。更重要的是，还有可能因为程序员的失误造成内存错误，例如：
l 试图分配超过可用物理内存数的内存
l 忘记释放内存
l 继续使用已被释放的内存
l 对已分配内存进行越界使用
应强制所有模块位于固定大小、预先分配的存储区域中，借此可避免此类问题，并简化内存使用情况的验证工作。未分配内存的情况下，动态请求内存的唯一方式是使用栈内存。
━━━━━
4、不使用冗长的函数
任何函数的长度不应超过使用标准参考格式 （每个声明最多一行、每个语句最多一行）， 也就是在 打印的纸张上一页纸所能容纳的字符数——这意味着函数的代码不应超过60行。
┇ 原因： 过长的函数通常意味着结构并非最优，每个函数都应是可理解、可验证的单一逻辑单位。如果在计算机显示器上需要多屏界面才能完整显示，这样的逻辑单位通常会极难理解。
━━━━━
5、低断言密度
图片来源：rankred
程序的断言密度 （assertion density） 应平均保持为每个函数最少两个断言，断言可用于检查现实运行过程中本绝不应出现的异常状况。因此应定义为 Boolean 测试。当断言失败后，应执行明确的恢复操作，如果静态检查工具证明断言绝对不会 Fail 或 Hold，则可认为未遵守该原则。
┇ 原因： 业界的代码编写工作统计报告显示——通过单元测试可发现，通常我们所编写的每10-100行代码中至少会存在一处缺陷。随着断言密度的增高，拦截缺陷的机会也会增大。
断言的另一个重要之处在于，它是防御性编程 （Defensivecoding） 策略的重要组成部分。我们可以使用断言验证函数执行前后的状况，函数的执行参数和返回值，以及循环不变式 （Loop-invariant）， 在完成性能关键代码的测试工作后，可将断言选择性地禁用。
━━━━━
6、以最小范围级别声明数据对象
该原则同时也是数据隐蔽 （Data hiding） 的基本原则。所有数据对象均必须以尽可能最小的范围级别进行声明。
┇ 原因： 如果某对象不在范围内，意味着其值将无法引用或已损坏。该原则不鼓励出于多种可能导致故障诊断工作变得更复杂的互斥意图重用变量。
━━━━━
7、检查参数和返回值
应在每次调用函数后检查非空函数的返回值，并应在每个函数内部检查参数的合法性。在最严格的形式下，该原则意味着就算 printf 语句和文件 close 语句的返回值也应进行检查。
┇ 原因： 如果对错误结果的响应与对成功结果的响应没有任何区别，那么很明显需要检查返回值。通常对 close 和 printf 的调用便符合这种情况，此时一种可行的方法是将函数的返回值明确抛出给 void，这意味着开发者明确 （而非意外地） 决定忽略该返回值。
━━━━━
8、限制预处理程序的使用
预处理程序 （Preprocessor） 应仅限用于头文件和宏定义。递归的宏调用、令牌传递，以及变量参数列表均不允许使用。
就算大型应用程序开发工作中，标准样板文件 （Boilerplate） 之外也可能有必要使用一两个以上的条件编译指令，这是为了避免将同一个头文件包含多次。每个这种用法必须通过工具检查器添加标记，并通过代码阐述原因。
┇ 原因： C 语言预处理程序是一个强大但较为含糊的工具，有可能彻底破坏代码的清晰度，并让很多基于文本的检查器产生混淆。就算具备正式的语言定义，包含无界限预处理程序代码的构造也会显得非常难以解读。
有关条件编译的注意事项同样很重要，就算只使用10个条件编译指令，代码也有会产生1024（2^10）个可能的版本，这会导致测试工作量剧增。
━━━━━
9、限制指针的使用
指针的使用必须加以限制。通常只允许不超过一层的解引用 （Dereferencing）， 指针解引用操作不应隐藏在 typedef 声明或宏定义内部，此外函数指针也是不允许使用的。
┇ 原因： 指针很容易被滥用，就算专家也难以彻底避免。指针的存在会使得我们难以跟踪或分析程序中数据的流动，尤其是在使用基于工具的静态分析器执行这些操作时。
函数指针还会对静态分析器所能执行的检查类型产生限制，因此除非有非常必要的理由，否则一般不推荐使用。如果使用函数指针，通常将 几乎 无法通过工具证明递归的缺席，此时只能提供其他方法弥补这种分析能力的缺失。
━━━━━
10、 编译所有代码
从开发工作第一天开始时，就必须对所有代码进行编译。必须启用编译器的警告功能，并使用最细致的检查选项。代码必须能通过这样的设置、在不产生任何警报的情况下顺利编译完成。
所有代码必须每天一次、且使用至少一种 （多种则更好） 最新型的静态源代码分析器进行检查，并且必须顺利通过分析器的整个检查过程而不产生任何警告。
┇ 原因： 市面上有很多效果卓越的源代码分析器，其中很多甚至是以免费软件的形式发布的。对于这样可以直接使用的现成技术，任何软件开发工作都没理由不加以充分利用。
如果编译器或静态分析器遇到问题，导致问题或错误的代码必须重写，这样才能进一步改善代码质量。
以上这些准则是基于 NASA 喷气推进实验室首选的 C 语言，但同样适用于其它编程语言。它们 就如同汽车安全带，也许一开始会让你觉得有些不舒适，但一旦用上它们，过不了多久，就会变成每个人的第二本能，到时候如果不这么做反倒会觉得不舒服。
所以~谁说码农只能灰头土脸埋头苦干，人类上天入地的各种探索其实都离不开最最基础的编程工作啊！你看，这些代码不就“上天”了嘛！
各位程序猿、程序媛们，用上“航天标准”的编码准则，撸起袖子加油干吧！ 
━━━━━
今日互动话题
在你的码农生涯中，
有没有哪一次的bug曾让你
哭笑不得？
[ 参考资料 ]
-《Applying NASA coding standards to JavaScript》：http://pixelscommander.com/en/javascript/nasa-coding-standarts-for-javascript-performance/
-《NASA’s 10 rules for developing safety-critical code》：https://sdtimes.com/nasas-10-rules-developing-safety-critical-code/
-《NASA’s 10 Coding Rules for Writing Safety Critical Program》：https://www.rankred.com/nasa-coding-rules/
更多 你可能想了解的内容
注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。