下面是 可测试性 领域内容的几个例子。

　　设计是否允许运行时外部工具访问“状态”变量（例如，当前状态），特别是那些测试程序需要用来验证代码是否正确工作以帮助确定问题的变量？

　　是否对跟踪和日志给予了足够的重视？您让其他人分析缺陷越容易，您在发现缺陷后修正它们越容易（而且在单元测试中发现自己的问题也会更容易）。

　　您是否考虑了所有可能调用您的代码的上下文？如果您可以将错误消息与调用它的用户函数上下文相关联，那么用户更有可能理解这个错误。

　　设计是否结合了您的测试自动化工具所需要的特定的“钩子（hook）”？

　　再多想一想您肯定可以在这个清单中加入更多的内容，特别是那些对您的产品或者组织特定的内容。

　　防御性编码技术：编译器是您的朋友

　　当您完成对设计的检查后，轮到编码了。让我们面对它，除了设计错误外，编码是惟一引入缺陷的地方。无论如何，您的测试程序和客户是不会加入缺陷的 —— 只有 您 会。我们都知道时间很紧张，但是如果您没有时间在第一次把它编写正确，那么您怎么能找到时间去修正它呢？花上一些时间，这会使您在以后的编码工作中更轻松。

　　防止缺陷的好方法之一是使用编译器。令人恐惧的是，开发人员在编译时通常选择使用低程度的警告输出，所以请启用编译的全部警告 —— 把即使将编译器配置为检查 所有方面 编译时也不产生一个警告当成编写代码的一个挑战。此外，对代码使用多种编译器使很多程序员获益 —— 这种方法有时会捕获不同的语法错误。

　　编码习惯

　　下面我们将抛砖引玉介绍几个好的编码习惯。我们不是要为您定义“佳编码习惯” —— 我们只是要您形成自己遵守的代码编写习惯。下面是几个供参考的佳习惯的例子。

　　在使用前初始化所有变量

　　您是否有一组可接受的默认值，特别是对于可能被用户、其他组件或者其他程序有选择地修改的数据？同时，我们强烈要求您列出在外围例程中要使用的所有本地变量，然后再专门初始化它们。这样不会对您编写代码时的想法留下任何疑问。虽然这可能要多花一些时间并且像是没有理由地增加了几行代码，但是与只是在“运行中（on the fly）”声明本地变量相比，大多数优化编译器不会对此生成任何额外的运行时代码。清单 1 显示了在一个例程中初几行代码的一个例子：

清单 1. 初始化本地变量

　　使用一个“编码标准”文档

　　如果您有一个编码标准文档，使用它。您可以在 Internet 上找到许多种编码标准。找到一种简单的、切中要害、并为您留下一定的活动空间的标准。Sun 的网站有一个关于 Java 编程的编码规范的文章（请参阅 参考资料），它给出了拥有标准的下列几点理由：

　　一个软件生存期百分之八十的成本都用在维护上。

　　几乎没有软件在整个使用期间都是由原作者维护的。

　　编码规范改进了软件的可读性，使工程师可以更快和更充分地理解新代码。

　　如果您将源代码作为产品交付，那么需要保证它有像您创建的所有其他产品一样的包装和整洁性。

　　即使不赞成“标准”的想法，至少采用这个简单的建议：对变量名使用“匈牙利命名法”，这会使您的代码更容易阅读和维护。