美国宇航局（National Aeronautics and Space Administration，缩写为 NASA）是美国联邦政府的一个独立机构，负责制定、实施美国的民用太空计划、与开展航空科学暨太空科学的研究。在太空计划之外，美国国家航空航天局还进行长期的民用以及军用航空航天研究。
在普通人的眼中，NASA是一个很“高级”的机构，其成员包含大量不同领域的科学家和研究人员。与其他任何组织机构类似，NASA的日常工作，以及所执行的几乎全部项目也离不开计算机的辅助，出于需求的特殊性和重要性，他们所使用的很多计算机软件都是内部自行开发的，在一些重要项目的关键领域发挥着作用。
去年，一位前NASA实习生把美国阿波罗登月项目的11号计算机 --- 阿波罗导航计算机 (Apollo Guidance Computer) 系统源代码上传到了 GitHub，此举在开发者群体中引起了极大的热议。
此外，NASA官方也已将自己的部分源代码开源到GitHub，让我们得以管窥这一顶尖科研机构内的聪明大脑们写代码的专业水平。
大型的复杂软件项目通常会遵循一定的代码编写标准和指南。这些指南奠定了软件开发过程中必须遵守的基本原则：
-
代码的结构如何安排？
-
应不应当使用哪些语言特性？
出于效果的角度考虑，这些原则必须尽可能精简并且必须足够具体，这样才能更好地被人理解并记忆。
本文将介绍由NASA喷气推进实验室首席科学家Gerard J. Holzmann所提出的，侧重于安全参数的10条代码编写原则。当然，这些原则也适用于其他编程语言。
为NASA工作的全球顶尖程序员在编写高度安全的代码时就沿袭了这样的一套指南。实际上，很多组织，包括NASA喷气推进实验室主要会选择使用C语言编写代码。
原因在于这种语言具备完善的工具支持，包括逻辑模型分离器、调试器、静态编译器、源代码分析器，以及度量工具等。
有时候，编写代码必须遵守一定的原则，尤其是在代码的正确性会对人的生命产生决定性影响的领域，例如飞机、将宇航员送上同步轨道的航天器，以及距离居住地仅几英里远的核电站等设施运行的控制代码。
使用尽可能精简的控制流程构造编写程序 – 不要使用setjmp或longjmp构造、goto语句，以及直接或间接的recursion。
原因：简化控制流程有助于提高代码清晰度，增强代码可验证能力。不使用递归，便不会产生循环的函数调用图，这样也可证明所有本应有界的执行实际上都是有界的。
所有循环必须有固定次数的上限。我们可以通过验证工具静态地证明，为循环中迭代数量所设立的上限次数未被超越。
如果无法以静态方式对循环的次数界限加以证明，则可认为未遵守该原则。
原因：为循环设置次数界限，避免使用递归，这些做法有助于预防代码失控。然而该原则无法适用于本就不应终止的迭代（例如进程调度器）。此时将沿用该原则的逆向原则：必须能够静态地证明迭代不能终止。
不要在初始化完成后进行动态内存分配。
原因：诸如malloc等内存分配机制，以及垃圾回收器通常会产生无法预知的行为，进而可能会对性能产生影响。更重要的是，还有可能因为程序员的失误造成内存错误，例如：
-
试图分配超过可用物理内存数的内存
-
忘记释放内存
-
继续使用已被释放的内存
-
对已分配内存进行越界使用
应强制所有模块位于固定大小、预先分配的存储区域中，借此可避免此类问题，并简化内存使用情况的验证工作。
堆中未分配内存的情况下，动态请求内存的唯一方式是使用栈内存。
任何函数的长度不应超过使用标准参考格式（每个声明最多一行，每个语句最多一行）打印的纸张上一页纸所能容纳的字符数。这意味着函数的代码不应超过60行。
原因：过长的函数通常意味着结构并非最优。每个函数都应是可理解且可验证的单一逻辑单位。如果在计算机显示器上需要多屏界面才能完整显示，这样的逻辑单位通常会极难理解。
程序的断言密度（Assertion density）应平均保持为每个函数最少两个断言。断言可用于检查现实运行过程中本绝不应出现的异常状况，因此应定义为Boolean测试。当断言失败后，应执行明确的恢复操作。
如果静态检查工具证明断言绝对不会Fail或Hold，则可认为未遵守该原则。
原因：业界的代码编写工作统计报告显示，通过单元测试可发现，通常我们所编写的每10-100行代码中至少会存在一处缺陷。随着断言密度的增高，拦截缺陷的机会也会增大。
断言的另一个重要之处在于，它是防御性编程（Defensive coding）策略的重要组成部分。我们可以使用断言验证函数执行前后的状况，函数的执行参数和返回值，以及循环不变式（Loop-invariant）。在完成性能关键代码的测试工作后，可将断言选择性地禁用。
该原则同时也是数据隐蔽（Data hiding）的基本原则。所有数据对象均必须以尽可能最小的范围级别进行声明。
