递归 2次调用 他们写的代码能上天！NASA的10条安全编码准则大公开(2)

━━━━━

5、低断言密度

程序的断言密度（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 声明或宏定义内部，此外函数指针也是不允许使用的。

┇原因：指针很容易被滥用，就算专家也难以彻底避免。指针的存在会使得我们难以跟踪或分析程序中数据的流动，尤其是在使用基于工具的静态分析器执行这些操作时。

函数指针还会对静态分析器所能执行的检查类型产生限制，因此除非有非常必要的理由，否则一般不推荐使用。如果使用函数指针，通常将几乎无法通过工具证明递归的缺席，此时只能提供其他方法弥补这种分析能力的缺失。递归 2次调用

━━━━━

10、编译所有代码

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

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

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

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

以上这些准则是基于 NASA 喷气推进实验室首选的 C 语言，但同样适用于其它编程语言。它们就如同汽车安全带，也许一开始会让你觉得有些不舒适，但一旦用上它们，过不了多久，就会变成每个人的第二本能，到时候如果不这么做反倒会觉得不舒服。

所以~谁说码农只能灰头土脸埋头苦干，人类上天入地的各种探索其实都离不开最最基础的编程工作啊！你看，这些代码不就“上天”了嘛！

各位程序猿、程序媛们，用上“航天标准”的编码准则，撸起袖子加油干吧！

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-55664-2.html