变量

• 尽量减少变量的作用域。把对变量引用集中到一起，应尽量使变量成为局部或模块，避免使用全局变量
• 使每个变量有且仅有一个功能
• 并不是因为全局数据危险才避免使用它们，之所以避免使用它是是因为可以用更好的技术来代替它
• 如果全局数据的确不可避免的话，应通过存取子程序来对其进行存取操作。存取子程序不仅具备全局变量和全部功能，，而且可以提供更多的功能。

基本数据类型

常数

• 代码中是否避免了“奇异数”（常数？）
• 程序中是否采用了措施来防止出现被”0”除错误？
• 类型转换是否显示进行的吗？
• 如果再同一个表达式中出现了两种不同类型的变量，是否对表达式按照你的意愿进行求值？
• 程序中是否避免了混合类型比较？
• 在编译过程中是没有警告的吗？

整形数

• 使用整型数相除表达式的结果是否与预期一致？
• 整型数表达式中是否避免了整形数溢出问题？

浮点数

• 是否避免了数量级相差过大的数之间加减运算？
• 程序中是否系统地采用措施来防止舍入误差问题？
• 程序中是否避免了对浮点数进行相等比较？

字符和字符串

• 程序中是否避免了常数项字符和字符串？
• 对字符串的引用是否避免了边界错误？
• 若是用C语言写成的程序，是否把字符数组和字符串指针区别对待的？
• 若是用C写成的，是否遵守了把字符串长度说明为CONSTANT+1这一约定？
• 是否用字符数组代替指针？
• 在C语言程序中，是否把字符由初始化成了NULL以避免出现无限长字符串？
• 在C语言中，是否使用strncpy()代替了strcpy(), 并且用了strncat()和strncpy()?

逻辑变量

• 程序中是否使用了附加的逻辑变量来说明条件判断？
• 程序中是否使用了附加的逻辑变量来简化条件判断？

枚举类型

• 程序中是否用枚举类型代替了命令常量来改善可读性，可靠性和易改性？
• 是否用了枚举类型代替逻辑变量以改进可读性和灵活性?
• 在使用了枚举类型的判断中是否检查了无效值？
• 枚举类型的第一个入口是否保留为无效的？

命名常量

• 在数据说明中使用的是命名常量吗？
• 是否一致地说明了命名常量，而不是一会儿使用了命令常量，一会儿使用数值？

数组

• 是否所有的下标都在数组界限之内？
• 是否对数组所有的引用都没有发生越界错误？
• 多维数组的小标排列顺序正确吗？
• 在嵌套循环中，作为循环变量的数组下标是正确的吗？是否出现了交叉错误？

指针

• 是否把指针操作独立在函数中？
• 指针引用是有效的吗？是否误用了悬挂指针？
• 程序中在使用指针之前，是否对它进行了检查？
• 在使用由指针指向的变量之前，是否对 其有效性进行了检查？
• 在释放指针之后，是否把它们的赋值成了NULL或NIL?
• 为了提高可读性，程序中是否使用了所有需要用的指针变量？
• 链表中的指针是否按正确的顺序释放的？
• 程序中是否分配了备用内存空间以作为内存溢出时拯救数据和工作努力的降落伞？
• 是否在万不得已是才使用指针的？

复杂数据类型

• 恰当地对数据进行结构化，可以是程序更简单，更容易理解也更容易维护
• 可以用表来替代复杂的逻辑结构。当你被程序逻辑迷惑时，应考虑是否可以寻表来简化程序。
• 抽象数据类型时降低复杂性的有力武器，它使你可以分层编写程序，而且是从问题域而不是程序语言细节来编写顶层的程序。

顺序程序语句

• 组织顺序是代码最好的原则是整理出以来关系
• 用合适的子程序名，参数表，注释来标明依赖关系
• 如果代码没有明显依赖关系，把相关语句组织在一起，特别是使用同一参数的那些语句。

条件语句

• 注意if和else的顺序，特别是在处理好多异常情况时，务必使正常情况流向清晰
• 组织好if-then-else和case语句的几种情况，使可读性最好
• 在case语句中用缺省值，在if-then-else中的最后一个else中获取意外错误
• 各种控制结构并不都同样有用，在编码时选用最合适的控制结构。

循环语句

• 循环很复杂，使其简化有利于阅读
• 简化循环的技巧有：避免使用怪样子循环，使循环次数最小，使进出口清楚，把内务代码放在一个地方
• 循环控制变量不可滥用，应给它起一个有含义的名字并让它只起一个用途
• 仔细思考一下整个循环，保证循环在各种情况和终止条件下都能照常运行。

少见的控制结构

• 多重return有时增强了程序的可读性与可维护性，并且防止多重嵌套逻辑，但没必要只想到怎样用好return
• 在问题较简单时，递归调用能把问题很巧妙解决，要慎用递归。

常见的控制问题

• 使布尔型表达使简单可读性高对代码的质量很有好处
• 深层嵌套使程序难懂，不过可用相对简单方法避免这样做
• 结构化编程是一个简化程序的思想，用顺序编程，选择或循环中的一种或几种方法的组合可编写出任何程序。
• 作这种简化程序的思想可提高程序的产量和质量
• 如果所用语言不支持结构化结构，你能模仿它们。你应该把程序编成某种语言的程序而不是用某种语言编程的。
• 降低复杂性是编写高质量的代码的关键。

布局和风格

• 布局首先考虑的是去显示程序的逻辑结构。评价这种考虑是否达到目标标准有：准确性，连续性可读性，易维护性。好看的是第二条标准–比较弱的标准。如果以上几条标准都达到了而且程序也比较好看。那么布局一般就成功了。
• 结构化代码是有其自身目的的，你最好还是一些约定俗成的布局形式而少来创新，以保持与别人协调一致。若你的布局与约定的不一样，那么很有可能影响你程序的可读性
• 有关布局的好多观点纯属一个信仰或者所个人喜好问题，努力把客观需求和主观喜好分开。遵从一些明显地规划，以选择你所喜好的布局形式。

文档

• 是否注释就像是立法，注释得好，是非常值得的，注释得不好，则是浪费时间而且有害，源代码中应含有关于程序的绝大部分重要信息，只要程序还在运行，那么代码中注释便不会丢弃或被丢弃。把重要信息加入代码是非常重要的
• 好的注释是意愿层次上进行的，它们解释的是“为什么”而不是”是什么”
• 注释应表达出代码本身表达不了的意思，好的代码应是自说明的。当你对代码进行注释时，应问一下自己“如何改进代码以使得对其注释是多余的？”改进代码再加注释以使它更清楚

评审

• 总的来说，评审再发现错误方面较测试较好
• 评审侧重于错误发现而不是纠错
• 评审往往比测试要能发现更多不同的错误，意味着你应使用评审或调试的方法以确保软件的质量
• 使用检查表，准备良好的分工，连续的处理以便最大限度地提高检错能力，检查往往较普查能发现更过的错误。
• 普查和代码阅读时检查的候补方法，代码阅读可有效地利用每个人的时间

单元测试

• 开发者使用测试是完成测试策略的一个重要组成部分。
• 各种测试方法的混合使用也是搞好软件程序质量的一个方面，高质量开发方法，包括有条理地对需求和设计进行测试。检查和普查在发现错误方面也至少同调试方法一样有效，并且可发现各种类型的错误。
• 采用基本测试，数据流分析和错误猜测你可生成许多测试用例
• 错误倾向于集中在少数几个子程序中。找到这几个子程序，重新设计和重写它们。
• 测试数据往往比受测试的代码含有更多的错误。这种找错方法只会浪费时间而不会提高代码质量，测试数据错误往往比编码错误更令人讨厌。这可以通过仔细地进行测试来避免
• 最终提高测试质量的最好方法是，有条理地度量它，利用你的知识提高测试质量。

调试

• 调试是软件开发中的问题。最好的方法是使用本书的其他方法避免一开始就发生错误。你仍需花费时间提高你的调试技巧–因为最好和最差的调试效率差别为10：1，甚至更大。
• 注意你的编警告信息，并及时改正编译所提示的错误。如果你忽略了明显错误的话，你就难以改正微妙的错误。
• 发现和改正错误的关键是，有一个有条理的方法，注重你的测试，这样你都能向前迈进一步
• 在你改进一个问题之前应理解问题的本质，对错误的任意猜测和修改只会使你的程序更为糟糕。
• 调试时软件开发的有力工具，你应能利用调试工具。