NASA 的 10 大编程规则(c++)
第 1 条规则 — 简单的控制流
用非常简单的控制流结构体来编写程序 — 不要用 setjmp 或者 longjmp 结构体，goto 语句，以及直接或间接的递归调用。
理由：简单的控制流能够提高代码的清晰度以及拥有更强大的验证能力。不使用递归，就不会产生循环函数调用关系图，同时这也证明应该是有界的执行过程确实是有界的。
PS：这也是“结构化编程”的一个表现。控制流要清晰，一下就能看明白。此外，感觉回调也尽量少用，即使用了，也要保证逻辑清晰。
第 2 条规则 — 循环设置固定的上限
所有的循环必须有一个固定的上限。对于检查工具来说，在给定循环次数的情况下，可以通过静态分析证实循环结果不超过预设的上限。如果工具不能静态检测出循环上限，那么这条规则就不适用。
理由：设置循环边界、不使用递归能够阻止代码失控。但是这个原则并不适用于迭代，迭代意味着无穷无尽（比如进程调度）。 这种情况下就该使用相反的规则 — 必须可以静态地检测到迭代不会终止。
PS；没有固定循环的上限的情况目前遇到的倒是不多。
第 3 条规则 — 没有动态内存分配
初始化之后不要使用动态内存分配。
理由：内存分配运算符比如 malloc 以及 garbage collectors 通常伴有不可预测的行为，这些行为会严重影响性能。甚至还可能因为程序员的错误而发生内存错误，包括：
•试图分配比物理内存更多的内存空间 •忘记释放内存 •继续使用已经释放了的内存 •超出内存分配的边界
将所有的模块强制存放在固定的、预先分配的内存空间中，可以消除这类问题，同时验证内存的使用情况也会更加容易。
在堆中内存分配不足的情况下进行动态申请内存的一种方法是使用栈内存。
PS：这个比较严格的规范，貌似sony也有这个的规定。写代码的过程可以尽量的避免，也是RAII的一种实现，但是如果是大对象，不new的话，而且没有预先分配的内存的话，此条还是可以僭越的。
第 4 条规则 — 没有大函数
如果以一行一条声明和一行一条语句这样标准的格式来写，那么函数的长度不应该超过一张纸。这也就是说一个函数不应该超过 60 行代码。
理由：冗长的函数通常等于糟糕的代码结构。每个函数应该是一个易懂可证实的逻辑单元。而理解一个多屏幕长的逻辑单元是很困难的。
PS：60行，一张纸。
第 5 条原则 — 低断言使用密度
代码断言的密度应该低至平均每个函数两个。断言是用来检查现实执行中不会发生的不正常情况。它应该被定义为布尔测试。当断言失败，应当立即采取恢复措施。
如果静态检测工具证明断言永远不会失败或者条件永远不为真，这条规则就无效。
理由：工业编码工作统计显示，单元测试中每 10 到 100 行代码至少发现一个代码瑕疵。随着断言的密度增长，有瑕疵的代码被拦截的几率越大。作为强大的防御型代码策略，断言的使用也是非常重要的。断言可以用来验证函数的前后条件、参数以及函数和循环不变式的返回值。在测试完效率关键代码后，断言可以选择性地禁用。
PS：断言，使用不多。
第 6 条规则 — 最小范围内声明数据对象
这条规则支持数据隐藏的基本原则。所有的数据对象必须在尽可能最小范围内声明。
理由：如果一个对象不在该范围内，其值也不能被引用或者销毁。这条规则阻止了变量的重复和冲突性的使用，这些行为会使错误诊断更加复杂。
PS：这也是衡量“代码复杂度指标”的一个重要参考。
第 7 条规则 — 检查参数和返回值
当函数的返回值为非空的时候，每次函数调用都应该检查其返回值，并且每个被调用的函数还要检查所带参数的有效性。
在最严格的模式下，这条规则意味着printf和文件关闭语句的返回值也要检查
理由：如果一个错误的返回值和一个正确的返回值没有什么区别的话，这个时候就有必要精确检查返回值。在函数中有调用 close 和 prinf 语句的情况下，函数返回值是 void 能够被接受，表明程序员故意（并且不是偶然）忽略返回值。
PS：忽略这条往往非常容易产生问题。以后要加强，不要求在错误的地方打日志，至少返回一个错误码先。除非void返回，其他都要最返回值检查。
第 8 条规则 — 限制使用预处理器
预处理器的使用应该限制在头文件和宏定义中。不允许使用递归宏调用，拼接符和可变参数列表。即使在大型程序的开发工作中，如果使用了超过一两个条件编译指令必须要有充足的理由，这么做超出了统一的代码标准，同样也是为了避免同样的头文件包含多重释义。每次这么做必须在代码中要有由基于工具的检查器进行标记并且要有充分的理由。
理由：C语言的预处理器是一个非常强大并且难懂的工具，它能够破坏代码的清晰性并迷惑基于文本的检查器。即使手上有正式语言定义，在无尽的预处理器代码中，代码的结构也是很难理解的。
条件编译也同样需要谨慎，10 个条件编译指令代码中就会有 1024（2^10）个不同版本的代码，这也增加了测试的工作量。
PS：宏=难懂，不推荐
第 9 条规则 — 限制使用指针
必须要限制指针的使用。最多只允许使用一级指针解引用。指针解引用操作不可以隐藏在类型声明或宏定义中。还有，不允许使用函数指针。
理由：即使是专家，也很容易误用指针。指针使得它们（尤其是基于工具的静态分析器）很难跟踪或分析程序中的数据流。函数指针还限制了静态分析器的检查类型，只有在理由非常充分的情况才能使用函数指针。如果使用函数指针，几乎不可能使用工具来证明缺少的递归，所以必须有足以弥补这部分缺失的分析能力的替代方法。
PS：指针=容易犯错。适当的使用一些scope ptr也是可以的。尽量少用，同样指针也往往意味着动态分配内存，与第三条一起更不推荐了。
第 10 条规则 — 所有代码必须能编译通过
从开发的第一天起，所有的代码都必须通过编译。所有的编译器警告必须遵循编译器可使用警告。在编译器可使用警告范围内，编译的代码必须没有警告。
所有代码必须每天至少使用一个（最好多于一个）最新的静态源代码分析器进行检查，而且以0警告通过所有的分析。
理由：市场上有很多相当有效的源代码分析软件，其中一些还是免费的。软件开发项目没有任何理由不去使用这个现成的技术
如果编译器或者分析器被搞混淆了（报出错误的警告），那么应该重写使其混淆的这部分代码。
PS：对于新开发的代码，做到此点并不难。
NASA 是这么评价这些规则的：
“它们就像车里的安全带：刚开始用会有点不舒服，但是过了一段时间就会成为一种习惯，你会无法想象不使用它们的日子。”