https://www.rankred.com/nasa-coding-rules/

原则1 – 简化控制流程（Simple Control Flow）

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

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

原则2 – 为循环使用固定次数上限（Fixed Upper Bound for Loops）

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

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

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

原则3 – 不使用动态内存分配（No Dynamic Memory Allocation）

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

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

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

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

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

原则4 – 不使用冗长的函数（No Large Functions）

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

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

原则5 – 低断言密度（Low Assertion Density）

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

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

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

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

原则6 – 以最小范围级别声明数据对象（Declare Data Objects at Smallest Level of Scope）

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

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

原则7 – 检查参数和返回值（Check Parameters and Return Value）

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

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

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

原则8 – 限制预处理程序的使用（Limited Use of Preprocessor）

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

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

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

原则9 – 限制指针的使用（Limited Use of Pointers）

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

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

原则10 – 编译所有代码（Compile all Code）

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

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

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

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

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

=>更多文章请参考：《中国互联网业务研发体系架构指南》

=>更多行业权威架构案例及领域标准、技术趋势请关注微信公众号 '软件真理与光'：

NASA关于编程的十条原则相关推荐

编程的首要原则(s)是什么？
半年前,JoelOnSoftware和CodingHorror合搞的stackoverflow.com刚上线不久,我兴冲冲地跑过去扔了一个问题: 你们认为编程的首要原则是什么? 作为我的学习原则的一个 ...
【Computer Organization笔记07】实验课：可编程逻辑器件介绍，硬件编程方法与原则，硬件编程流程
本次笔记内容: P13 计算机组成原理(13) P14 计算机组成原理(14) 本节课对应幻灯片: 组成原理52 verilogHDL 组成原理53 fpgahardware 本节课内容为" ...
面向对象编程，设计原则，设计模式
2019独角兽企业重金招聘Python工程师标准>>> 面向对象编程,设计原则,设计模式面向对象编程面向对象编程与面向过程编程的区别面向对象软件开发的优点面向对象编程语言 C ...
嵌入式编程规范与原则
嵌入式编程原则和规范编程规范编程原则编程思想架构思想 IDA分层思想函数编写原则模板示例编程规范 1.文件名尽可能以模块名命名,统一小写(根据个人风格调整).如led模块led.c.le ...
编程的首要原则是什么？
编程的首要原则是什么? 学习一项知识 1. 它的本质是什么.2. 它的第一原则是什么.3. 它的知识结构是怎样的. 1. 未雨绸缪: 写代码时时刻设想你就是将来要来维护这坨代码的人.写API时时刻设想 ...
软件开发编程规范及原则
推荐分享一个大神的人工智能教程.零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到人工智能的队伍中来!http://www.captainbed.net/strongerhuang 我的网站:h ...
制定城市大脑建设标准应遵循的十条原则探讨
作者:刘锋本文发表于2022年3月<中国建设信息化杂志> 2015以来,城市大脑被提出并成为前沿科技和智慧城市建设领域的新热点.到2022年,全国已经有包括北京.上海.杭州.深圳.郑州. ...
NASA顶级程序员编程十大原则
2019独角兽企业重金招聘Python工程师标准>>> 导读引言: 你知道 NASA 顶级程序员如何编写关键任务代码么?为了确保代码更清楚.更安全.且更容易理解,NASA 的喷气推 ...
程序员的自我反省-十条原则
工作也有2年多了.在程序员的道路上慢慢成长ing,不时会反思,不时看大佬的博客学习,总结,分享. 今天就看了美团技术团队博客的一篇文章. 写给工程师的十条精进原则切合自动不足点简要反省一下. 内容简 ...

NASA关于编程的十条原则