作者:江南白衣 

     昨天翻翻《程序设计实践》的Debug一章,里面用C写的例子早已被风吹的没了颜色,不随语言流转的就只有结尾那几句经验谈。但大学里向来是连这几句话也懒得教的,一定要大家从“put print statements in the program to find the bug” 开始,和bugs共同生活几年后,自个养成条件反射式的debug习惯。

     面对Bug,正确的生理反射应当是找线索而不是直接跳到Step 2蛮干:
        一、找熟悉的模式。人应该了解自己当然也包括自己常犯的错误,还有是检查那些经常犯事的代码模块。
        二、最近改过的代码。
        三、如果错误是由特定数据和操作引起的,思考这些输入的特征。
        四、如果是系统模块输出的错误,第一时间拷下来google。(不过也要提防有些系统的输出信息完全不靠谱)

    找没找到线索,然后都要开始定位错误。
    定位的方法,是经典不过的--分而治之:注释一些代码,减少、hardcode一些输入值和中间值,函数返回值等等。
    如果没有明显的线索,可单步执行,同时察看多个变量的debug工具就要及早出场,它能让你看到程序实际的执行情况而不是你思想里早就预设的误区。
    不过,断点设在哪里,先注释、hardcode哪些代码这种深刻决定debug效率的抉择,就很讲经验和最近的运势了!

     如果埋头苦干都没有结果,那可能是思维有了误区,就该拉个人过来和你聊一下天气和这个bug啦(但是注意别拉到太笨的,鸡和鸭讲的)。又或者,再回头看看是不是一些极低级的错误,比如链接库的版本错啦,根本没有重编译啦....

     改完bug后,好习惯是再看一眼别的地方中会不会还有同类的虫虫没杀掉。

    ----延伸阅读《Code Complete 2nd》中Debugging 一章。