debug的一点总结

程序员常常需要和bug打交道，一般来说调试bug的时间要多于编写程序的时间。

bug可以简单的分为两大类：

1. 语法上的bug
2. 逻辑上的bug

语法上的bug就是指编译器能够识别的，例如常见的缺少分号和括号，传参时数据类型不匹配，这一类的bug是比较容易调试的。可以直接根据输出信息找到对应的错误语句。

逻辑上的bug就很麻烦了，这样的bug编译器是不会显示出来的。例如最常见数组越界，非法访问内存这些问题编译器都不会去识别，只有程序在执行的时候才会显示出来。这个时候我们常常通过会将程序分块，来判断程序可以执行到哪一步。这个时候一般有两种常用的方法：

1、设置断点

现在的IDE都提供了这个功能，当程序运行到断点处就会直接停下来。

2、人为的加上输出语句

例如C语言可以用printf语句来判断程序可以执行到哪一步。

这两种方法各有优缺点，《麻省理工：计算机科学编程导论》的时候讲到调试时需要注意的事情。感觉挺好，特记录下来。（另，课程中提到，“print”和“重新阅读代码并思考”是很重要的方法。确实，有时候调试工具的单步调试会让你局限于细节，而没有从整体上去观察思考代码。不过 有时候调试工具也能给我们带来很大帮助。也许两者结合起来会让调试更加有效率吧）

下面是debug的一些经验总结：

1. 自变量顺序错误。（注意参数命名，以避免颠倒顺序。实参和形参用相同的名字会调理清晰）
2. 拼写错误。
3. 忘记初始化。
4. 对象与值相等。“==” 与" = "
5. 别名。数组、链表的深度复制和浅复制。
6. 副作用。函数执行过程可能会改变一些变量的值。
7. 收集自己经常犯的错误，调试时先从易犯的错误下手。
8. 记录你尝试过的修改，调试用的“print”可以注释掉而不是删除。
9. 调试别人代码的时候，调试的是代码，而不是注释。不要被注释所迷惑。
10. 寻求帮助。旁观者清，寻找别人帮助，尽可能向别人解释清楚自己的程序，也许你在解释的过程中就能发现错误了。
11. 清醒一下大脑。
12. 欲速则不达。考虑好修改方案，而不是急功近利。修改这个bug的过程可能会产生更多的bug。
13. 代码不能总是变长。代码写的越多，出错误的可能就越大。当你遇到问题时，试着把你的代码整理一下，整理的过程中也许你就可能找到错误。
14. 及时备份旧版本代码。确保你的代码能够回到Debug前。没有什么比你Debug 4个小时，最后发现还没有4个小时前好，更令人沮丧的是你不能回到最开始的状态。硬盘空间很廉价，多保存一下旧版本的代码绝对没有坏处。

参考博文：http://alorry.blog.163.com/blog/static/647257082011664510817/