串口程序调试总结

最近，这一个月都在看公司一份近60W行的代码，因为自己算法、硬件等基础很差，看起来不是一般的累.....

 

只能靠F5、F10来不停的调试，勉强看完这份代码，我自己只能是从心底里拜模！我的一些心得，希望能给友友帮助：

 

调试能否成功一方面在于方法，另外很大程度上取决于个人的经验。但是在调试的时候，通常要遵循以下一些原则：

 

1、确定错误的性质和位置

分析、思考与错误征兆有关的信息，避开死胡同。调试工具只是一种辅助手段，充分利用VC自带的调试工具可以帮助思考，但不能代替思考。通常避免使用试探法，最多只能将它当作最后的手段。毕竟小概率事件有时也会发生。

 

2、修改错误的原则

在出现错误的地方，很有可能还有别的错误。修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有找到源头修改错误本身。小心修正一个错误的同时又引入新的错误。

 

3、绘制程序流程图

很多人都认为这个是件繁琐的事，而且浪费时间。其实不然，当你读要一个诺大的程序一筹莫展时，面对纷纷复杂的关系理不出头绪时，使用流程图绝对可以事半功倍。

 

4、不要过多的依赖F10

调试串口程序与调试其他程序（如数据库）不一样，串口程序对时间很敏感。串口上的数据只在一瞬间有效，可谓稍纵即逝。所以等到地F10单步执行到那里时，串口上的数据早已更改了，当然调试也不会得到什么有意义的结果。

 

5、变量的定义

变量名一定要有意义，而且在同一个程序中，同一个变量只让他做一件事。不要为了节省空间，一物多用。现在的计算机可以说内存是足够大，多几个变量不会对程序的性能有本质的影响。但是变量也不要随手写，我看到这份代码中，常常有精确到BYTE，所以这里一定要规范，不然，到最后你往里面扔了一大堆UDP包，结果自己都会结舌。

 

6、程序的结构

合理地设计程序结构。在面向对象的程序设计中，将相关的功能做成一个成员函数，尽量降低各成员函数间的耦合性。其实，在过程化程序设计中，就是代码模块化的表现。这份代码由算法设计、界面模块、通讯模块、错误处理模块等等都是相当的完美，所以我是发自心底的佩服。

 

7、修改代码的原则

在程序彻底正常运行前，绝对不要轻易地删除一段代码，即使你当时认为这段代码肯定是错的或无用的。现在的集成开发环境比如VC都提供了良好的注释工具，将暂时认为错误的代码注释掉要优于直接删除。若同一段代码修改多次，还应该在代码后面注明修改的时候、原因等，这些信息将在后续的调试与维护中，会给你带来莫大的帮助。

 

8、检查循环语句

循环语句经常是造成程序没有任何相依的罪魁祸首。详细检查程序中使用的每一个循环语句，尤其是while()循环语句。

 

9、与外部设备打交道

程序中，当操作文件、打开串口时，一定要编写出错处理的代码。因为这些硬件设备随时、随机都有可能不满足编写程序时的条件。

 

10、数组与循环的上下限

为了简化代码，对于大量的、有规律的数据处理，通常都会采用数组或循环来实现。那么，你一定要小心了，设置的数组下标是否能满足实际数据需要，循环的上下限是否漏掉数据的那两个起始值。

 

11、无效句柄或指针

这种问题相信大多朋友都会常常遇到，也许编译连接都没有问题，但运行句出现了致命的bug、什么XXO内存不能read等等，其实都是一样 “形象”的问题，所以这时候请你多写些ASSERT()或其他SEH处理代码。

 

12、屏蔽无关的代码

当调试某个功能的代码时，为了缩小查找范围，完全可以注释掉与其无关的其他代码，或者注释掉该代码的某个分支，这样会加快找到问题的确根源。