R Debug的常用方法

用R也有一段时间了，上学的时候写程序都处一种“能实现这个功能”就可以了状态，工作后这一年多时间，在写程序这件事上也陆续成长了不少，最明显的就是“模块化”思想和比较“defensive”的语句写法，在实际使用中受益最大。关于编程思想，推荐编程的智慧一文，文末附链接。

编程时Debug其实没什么难理解和神秘的，刚开始的时候我对于用和还有点畏难，其实你写一段程序，运行发现有问题，从第一行开始一点一点执行去找到这个问题改过来，就是debug过程了，只是有些函数能帮助我们把这一过程更方便和高效的处理而已，人对自己没接触过的东西难免觉得神秘和困难，其实用几次就发现也就那么回事。。

Debug时常见做法及思想

debug的时候采用自上而下的，模块化的调试风格，先调最外面的函数，比如,在中用到了函数，不要调用，现在的状态下，去执行中含的看是否能得到想要的结果，如果是，则不需要去，省去从底层细节一个一个去调试小函数的时间。当然这样做有个问题，就是有可能执行的以后结果是对的，但其中其实有错，这就需要执行的时候把所有参数都输入全，多种状态下都考虑到。退一万步讲，即使到最后都执行完了没发现问题仍然需要回来调试底层的小程序，总体上来看也是这种方式比较省时间的，而且脑子里会有一个宏观框架的概念。

在代码中插入一些语句如，不只是的时候有用，保存的时候也没有必要删。

在代码中插入一些来确认当前的变量结果是不是自己想要的，但这种只适用于调试一两轮的简单情况，否则来去非常乱，容易分心。

总结一下R中的调试工具

试着用通俗的语言来解释一下调试过程：

R中调试的核心工具是“browser”翻译成“浏览器”，个人理解是一个空间，在这里面可以逐行运行代码进行检查。其实在当前工作空间中，人工debug也是能实现，只是比较繁琐，browser给我们提供一个虚拟空间，在里面做一些对debug更友好的优化，使用更方便高效而已。

跟在普通coding界面中逐行执行不一样，它会有很多优化的地方，比如你写一个循环，在普通交互界面下是不会把循环中的每一步给你逐行展示出来的，而browser状态下可以。另外，在普通coding的界面中，你想判断一个函数哪里有问题，需要自己先给函数的参数赋好值，然后一步步往下运行，赋值的所有中间变量都存下了；实际上我们知道一个函数执行完，中间用到的一些变量是不会在当前空间存储下来的，而browser状态下就不需要自己给这些参数赋值，我理解它会创造一个虚拟环境，赋值它都替你做好了不需要手动做，等调试完了出来以后这些中间变量也不会被保存下来，跟正常我们执行一个函数是比较像的。这样一来操作方便，二来逻辑上也比较干净，退出来以后不会影响当前空间的变量。

发现问题后的一般调试流程：

第一步：

和

运行一段代码发现错误时，可以用去找出问题发生在刚才运行的哪个函数中。

第二步：

和

上一步用定位到有问题的函数后，下一步用和。可以将,,理解为3个层面上的函数，是在你整个代码文件全部运行之后去找有问题的函数，函数的参数是你这个有问题的函数，是函数层面的，而是语句层面的，调用一次相当于在函数开始的第一行插入了一行。进入到状态以后，再执行一遍函数就会自动跳入调试界面，按回车一步一步执行。找到问题以后输入或者在Rstudio中单击即可退出browser状态。

另外几个细节：

debug()的另一种优雅写法：

函数能实现什么呢？

表示在每次进入函数的时候都自动调用函数。这个大概有很多广泛的用途，在debug的时候可以这样写，这与在函数第一样插入一条，保存后source原文件效果是一样的，这样做可以在不改变原文件的情况下，生成一个文件的临时副本，结束的时候即可。（实际操作中倒是觉得和加入一行去执行感觉差异不大，可能习惯问题吧。）

设置调试条件：当一个函数比较长，你比较确定问题出在后半部分，可以不用从第一行开始调试；或者知道在某些特定情况下才会出问题的，可以用(等价于)/这种条件来限制，节省调试时间。

控制调试次数：用进入对的调试后，默认每次执行的时候都会进入browser调试状态，如果想退出的话用退出调试环境。或者在只想一次的时候用。

参考内容：

《R语言编程艺术》 Norman Matloff著， 陈堰平 邱怡轩 潘岚锋等译 2013年第一版

编程的艺术（王垠）： http://www.yinwang.org/blog-cn/2015/11/21/programming-philosophy