便于调试的代码风格 排错的心理准备 尽量不用全局变量 所有变量都要初始化,成员变量在构造函 >排错的时间至少跟写程序一样长 数中初始化 ≯发现错误能够防止类似的错误再发生 尽量使用 const 最好自己发现错误,这样记忆比较牢固 详尽的注释 不要去怀疑编译器和库函数 虽然编译器和库函数可能有bug,但是出现 bug的可能性极其极其小 排错的错误定位 简单错误(1/3) 不要把所有的判断交给编译器和调试器 应该在程序中自己加以程序保护和错误定 大部分错误都是简单错误 ≯逆向推理,是否见过类似的问题 ·参数检查返回值检查 比如c语言中 使用异常机制 使用调试输出 scanf(%d”n) #define PR(x) cout<<#x="<<X<<'In 没有对局部变量初始化 日志输出 ·如果程序中的数值或者输出的结果很怪异,就 Log4cxX 很可能是上面提到的这几种错误 简单错误(2/3) 简单错误(3/3) 不要两次出现同样的错误 简单的排错步骤 ·改正一个错误之后,是否在别处也有过类似的 使用排错系统取得堆栈轨迹和几个变量的值 错误 发现出错的位置 简单代码非常熟悉,使我们放松警惕 读程序,而不是马上去改程序 ·比如多重循环中是否写错(这两个小样还是 ·比如 保证析构函数的异常在析构函数中得到处理 挺像的!) 在析构函数中释放内存时或者关闭s0cket时等 要保证基类的析构函数是虚函数 Father" f= new Child 低级错误: for (unsigned int i=10.p=0,-)-便于调试的代码风格 ¾ 尽量不用全局变量 ¾ 所有变量都要初始化，成员变量在构造函 数中初始化 ¾ 尽量使用const ¾ 详尽的注释 排错的心理准备 ¾ 排错的时间至少跟写程序一样长 ¾ 发现错误能够防止类似的错误再发生 z 因此最好自己发现错误，这样记忆比较牢固 ¾ 不要去怀疑编译器和库函数 z 虽然编译器和库函数可能有bug，但是出现 bug的可能性极其极其小 排错的错误定位 ¾ 不要把所有的判断交给编译器和调试器， 应该在程序中自己加以程序保护和错误定 位 z 参数检查,返回值检查 z 使用异常机制 z 使用调试输出 #define PR(x） cout<<#x”=”<<x<<'\n‘ z 日志输出 • Log4cxx • Log4j 简单错误(1/3) ¾ 大部分错误都是简单错误 ¾ 逆向推理，是否见过类似的问题 z 比如c语言中 int n; scanf(“%d”,n); z 没有对局部变量初始化 z 如果程序中的数值或者输出的结果很怪异，就 很可能是上面提到的这几种错误 简单错误(2/3) ¾ 不要两次出现同样的错误 z 改正一个错误之后，是否在别处也有过类似的 错误 ¾ 简单代码非常熟悉，使我们放松警惕 z 比如多重循环中i,j是否写错（这两个小样还是 挺像的！） 简单错误(3/3) ¾ 简单的排错步骤 z 使用排错系统取得堆栈轨迹和几个变量的值 z 发现出错的位置 z 读程序，而不是马上去改程序 • 比如： z 保证析构函数的异常在析构函数中得到处理 • 在析构函数中释放内存时或者关闭socket时等 z 要保证基类的析构函数是虚函数 Father *f = new Child(); delete f; z 低级错误：for (unsigned int i = 10; i>=0; i--){…}