NASA 的 10 大编程规则

稻香果甜

　　大型复杂的软件项目会使用某种编程标准或准则。这些准则组成了软件编写的基本规则。
　　

• 代码应该如何组织？　　
• 应该以及不应该使用哪些语言特征？
  

　　
　　为了确保有效，这些规则要简短并且足够具体，以便理解和记忆。
　　
　　那些为NASA工作的世界顶级程序员，在开发安全关键代码的时候遵守着一套准则。实际上包括NASA的喷气推进实验室（NASA’s Jet Propulsion Laboratory，JPL）在内的很多组织，主要使用C语言进行代码编写。
　　
　　原因是，C语言有大量的支持性工具，包括逻辑模型提取器、调试器、稳定的编译环境，以及在代码分析器和度量工具上拥有强大的资源。
　　
　　有时候非常有必要遵循编程规则，特别是当代码的正确性与你的生活息息相关的时候—用来控制你乘坐的飞机的代码，用来控制将宇航员送入轨道的太空船的代码，或者用来控制你家几英里远的核电站的代码。这里介绍的NASA的10大编程规则，主要偏重于安全参数，这10大规则是由NASA喷气推进实验室（JPL）的首席科学家Gerard J. Holzmann提出的。这些准则也可以用于其他编程语言。
　　
　　第1条规则—简单的控制流
　　
　　用非常简单的控制流结构体来编写程序—不要用setjmp或者longjmp结构体，goto语句，以及直接或间接的递归调用。
　　
　　理由：简单的控制流能够提高代码的清晰度以及拥有更强大的验证能力。不使用递归，就不会产生循环函数调用关系图，同时这也证明应该是有界的执行过程确实是有界的。
　　
　　第2条规则—循环设置固定的上限
　　
　　所有的循环必须有一个固定的上限。对于检查工具来说，在给定循环次数的情况下，可以通过静态分析证实循环结果不超过预设的上限。如果工具不能静态检测出循环上限，那么这条规则就不适用。
　　
　　理由：设置循环边界、不使用递归能够阻止代码失控。但是这个原则并不适用于迭代，迭代意味着无穷无尽（比如进程调度）。这种情况下就该使用相反的规则—必须可以静态地检测到迭代不会终止。
　　
　　第3条规则—没有动态内存分配
　　
　　初始化之后不要使用动态内存分配。
　　
　　理由：内存分配运算符比如malloc以及garbage collectors通常伴有不可预测的行为，这些行为会严重影响性能。甚至还可能因为程序员的错误而发生内存错误，包括：
　　

• 试图分配比物理内存更多的内存空间　　
• 忘记释放内存　　
• 继续使用已经释放了的内存　　
• 超出内存分配的边界
  

　　
　　将所有的模块强制存放在固定的、预先分配的内存空间中，可以消除这类问题，同时验证内存的使用情况也会更加容易。
　　
　　在堆中内存分配不足的情况下进行动态申请内存的一种方法是使用栈内存。
　　
　　第4条规则—没有大函数
　　
　　如果以一行一条声明和一行一条语句这样标准的格式来写，那么函数的长度不应该超过一张纸。这也就是说一个函数不应该超过60行代码。
　　
　　理由：冗长的函数通常等于糟糕的代码结构。每个函数应该是一个易懂可证实的逻辑单元。而理解一个多屏幕长的逻辑单元是很困难的。
　　
　　第5条原则—低断言使用密度
　　
　　代码断言的密度应该低至平均每个函数两个。断言是用来检查现实执行中不会发生的不正常情况。它应该被定义为布尔测试。当断言失败，应当立即采取恢复措施。
　　
　　如果静态检测工具证明断言永远不会失败或者条件永远不为真，这条规则就无效。
　　
　　理由：工业编码工作统计显示，单元测试中每10到100行代码至少发现一个代码瑕疵。随着断言的密度增长，有瑕疵的代码被拦截的几率越大。作为强大的防御型代码策略，断言的使用也是非常重要的。断言可以用来验证函数的前后条件、参数以及函数和循环不变式的返回值。在测试完效率关键代码后，断言可以选择性地禁用。
　　
　　第6条规则—最小范围内声明数据对象
　　
　　这条规则支持数据隐藏的基本原则。所有的数据对象必须在尽可能最小范围内声明。
　　
　　理由：如果一个对象不在该范围内，其值也不能被引用或者销毁。这条规则阻止了变量的重复和冲突性的使用，这些行为会使错误诊断更加复杂。
　　
　　第7条规则—检查参数和返回值
　　
　　当函数的返回值为非空的时候，每次函数调用都应该检查其返回值，并且每个被调用的函数还要检查所带参数的有效性。
　　
　　在最严格的模式下，这条规则意味着printf和文件关闭语句的返回值也要检查
　　
　　理由：如果一个错误的返回值和一个正确的返回值没有什么区别的话，这个时候就有必要精确检查返回值。在函数中有调用close和prinf语句的情况下，函数返回值是void能够被接受，表明程序员故意（并且不是偶然）忽略返回值。
　　
　　第8条规则—限制使用预处理器
　　
　　预处理器的使用应该限制在头文件和宏定义中。不允许使用递归宏调用，拼接符和可变参数列表。即使在大型程序的开发工作中，如果使用了超过一两个条件编译指令必须要有充足的理由，这么做超出了统一的代码标准，同样也是为了避免同样的头文件包含多重释义。每次这么做必须在代码中要有由基于工具的检查器进行标记并且要有充分的理由。
　　
　　理由：C语言的预处理器是一个非常强大并且难懂的工具，它能够破坏代码的清晰性并迷惑基于文本的检查器。即使手上有正式语言定义，在无尽的预处理器代码中，代码的结构也是很难理解的。
　　
　　条件编译也同样需要谨慎，10个条件编译指令代码中就会有1024（2^10）个不同版本的代码，这也增加了测试的工作量。
　　
　　第9条规则—限制使用指针
　　
　　必须要限制指针的使用。最多只允许使用一级指针解引用。指针解引用操作不可以隐藏在类型声明或宏定义中。还有，不允许使用函数指针。
　　
　　理由：即使是专家，也很容易误用指针。指针使得它们（尤其是基于工具的静态分析器）很难跟踪或分析程序中的数据流。函数指针还限制了静态分析器的检查类型，只有在理由非常充分的情况才能使用函数指针。如果使用函数指针，几乎不可能使用工具来证明缺少的递归，所以必须有足以弥补这部分缺失的分析能力的替代方法。
　　
　　第10条规则—所有代码必须能编译通过
　　
　　从开发的第一天起，所有的代码都必须通过编译。所有的编译器警告必须遵循编译器可使用警告。在编译器可使用警告范围内，编译的代码必须没有警告。
　　
　　所有代码必须每天至少使用一个（最好多于一个）最新的静态源代码分析器进行检查，而且以0警告通过所有的分析。
　　
　　理由：市场上有很多相当有效的源代码分析软件，其中一些还是免费的。软件开发项目没有任何理由不去使用这个现成的技术
　　
　　如果编译器或者分析器被搞混淆了（报出错误的警告），那么应该重写使其混淆的这部分代码。
　　
　　NASA是这么评价这些规则的：
　　
　　

“它们就像车里的安全带：刚开始用会有点不舒服，但是过了一段时间就会成为一种习惯，你会无法想象不使用它们的日子。”