来自http://hi.baidu.com/רҵͳ��ʦ/blog/item/7dd299faf7b7ac1e6c22eb72.html

SAS的DEBUG方面的内容比较少，现在我将网上的一些有关DEBUG的文章找了一些，然后整理了一下。

本文主要讲了SAS

debug的态度。本次也主要是讲一下态度，虽然有点像政治课，但是态度真的非常重要，编程的时候心态一定要放宽，不要太乐观地认为肯定没问题，一定要细

心地检查程序，思路要开阔，千要不要钻牛角尖，遇到实在解决不了的问题，就可先放一放，回过头来再看，有时就很容易地解决了。

在读本文的时候，我们首先要提醒几件事，一是所有的程序员在程序开发的过程中都会犯一些逻辑的或句法的错误，二是在debug一个程序的时候，你可以从解决这个问题的过程中学到很多该语言相关的东西。

本文主要分两章，第一章主要讨论bug的一些特性，以及在处理bug过程中，我们应该有的良好的态度。第二章主要讲解了一些SAS里可以用到的

debug的工具，本文DEBUG工具的东西讲得不够深入，点到即止，大家也就能知道一下其实DEBUG的工具还是比较多的，关键是我们如何灵活运用。本

文还着重强调了好的编码习惯的重要性(这个以前文章也有介绍)，书写清晰、避免漏洞、考虑好所有可能的逻辑路线，你就会发现你的时间都是用在开发而不是

debug上了。

debug是一门艺术。这一章主要讲解了正确应用debug工具的方法和态度。

1 什么是debug

Debug是识别错误产生的根本原因，并且修正这个错误的过程。这里要说明一下，首先我们要识别程序错误的根本原因，这样我们才能找出根本的解决方法。其次，这里强调Debug是一个过程，也就是说我们要用系统的方式不断地去尝试相关的方法来进行错误识别与错误修正。

那测试与debug有什么区别呢：debug是修复错误，也即是我们如何修正这个问题，而测试是程序验证，即这个程序输出的结果是否如预期的那样，它是否正确地执行了。

2 好的debug的态度和思想

在解决一个问题时，好的行为和态度跟好的工具一样重要。因此我们在解决问题时，我们不只是在修正这个程序，更重要的时我们在解决这个问题时学到的东西，使我们能成为一个更有经验的程序员。

2．1错误可能发生的范围：Bug无处不在

语法：可能由于误拼关键词，或者没加分号，或者类似其它的SAS无法处理的语句等等

逻辑：语法正确，程序可以运行。但是如果你没能把你要解决的问题正确地转换成程序函数功能时，就会出错或导致不正确的结果。这就要求我们仔细地检查log以及其他输出结果。

数据：数据源的更改，数据类型的改变，数据可能被删除，或者新数据超过了程序的处理范围，等等，这些情况都会导致错误

系统构架：由于程序一般是多人开发，当将这些不同的人单独开发并测试的程序或模块整合到系统的时候可能会失败，原因也多，比如程序本身有问题，或者整合过程有问题，或者系统配置也有问题。

实体连接：大多数程序都会与外面的数据文件、数据源、MACRO库等进行连接，但如果这些连接不正确的话就会产生错误。例如生产机与测试机的环境不一致，MACRO库的地址不一致等。

环境：即使是经测试的，使用过很长时间的代码，可能因为系统环境的小变化而导致失败。例如SAS版本，操作系统以及数据库版本的变化等。

上面的错误总体说来都是你自己的错误，因为这些你都应该非常清楚且能预先控制的。当然你也得考虑一下：

SAS软件错误：虽然很少发生，但SAS软件本身也会有Bug的。

系统硬件和软件：就像SAS系统一样，操作系统及硬件，网络连接等都会发生错误。

2．2了解你的编程行为：你的编程经验的深度和广度对Debug有着重要的作用，当然，自我检查的能力也同样重要。当出现现问题时，你要问一下自己：这个错误我以前是否见过，我是如何修正它的？

2．3不要拘泥于你最初的假设：很多错误的产生可能超出了自身的经验，因此依靠经验，但不要依赖于经验，不然自己就将限制在特定的解决思路了。

2．4彻底地描述问题：这里举了一个例子，我们要从web页面提交一个参数供后台处理，如果程序出现错误，你就要问一个这次提交的参数跟以前有什么

区别。你可能会知道原来用户提交了两个参数而不是一个，这时，你就要考虑如果将程序改成单选的话是否就会成功运行了。因此，你越能很好地描述这个问题，那

么你就越能更快地解决这个问题

2．5逐步开发和修正程序：无论是写一些简单的程序，还是写一些逻辑复杂或内容比较长的程序，或者是使用新的proc过程，我们最好将开发分成许多

小步聚，然后逐步开发并修正。道理很简单，如果我们只改变一处，出了问题，那么我们就修改这一处就行。如果改变五处，出了错误，我们就很难定位到是哪一处

或多处出了问题。

2．6不要惊慌，也许这只是一个小问题：在运行SAS程序时，有时候我们会了现SAS

LOG里出现一大堆错误和警告，这里不要惊慌，很可能这些错误只是因为一个小的原因造成的，比如下面的例子：

infile “c:\fin\curr\&curr..dat”;

retain month "&curr.";

input acct 1-6 suffix 7-9 $3. tranno 5.

trantype $2. amt 8.2;

run;

proc print data=this_mth(obs=100);

title "first 100 obs. from &curr.";

id branch;

run;

这里我们只是没有在第三行的末尾加上*/，结果在LOG里出现一大堆错误提示，结果我就不列出来了。所以有时候事情并没有想像中的坏。

2．7考虑一下其他的方法：如上面所说，但有时事情却真的跟想像中的一样坏。如果一个问题真的只能用很复杂的编码来解决，这时候你就要考虑一下其它

的方法了。SAS为我们解决问题提供了非常多的解决方法，比如data步时处理的数据，我们可以考虑用SQL或IML来进行处理。当然我们也并不仅限于软

件，当一个问题一直出现而得不到好的解决方法时，我们可以重新考虑一下数据的设计，变换，标准化，合并到一张表里等方法。

2．8逐步检查，拒绝假定：Be open to all

possibilities，就是不要忽略任何一种出现错误可能性。作者这里提到要像SAS编译器那样去检查程序，这里我自己编程经验不足，觉得比较难。

这里举了一个例子，input range_low 6. range_high 6

spec_low 5. spec_high 5.;

这里range_high的格式6后面差了一个点，我们如果一眼扫过去很难发现这个错误，因此检查的时候一点要细心。

2．9怀疑精神：任何的程序和系统都可能出现错误，因此，我们应该多问问以下问题：程序最近是否修改过，如果修改过，变化的部分是否经过测试，新的

代码与旧的代码有哪些区别，这些区别对现在的问题是否有影响？这个问题是否是以前的BUG，如果是，则可以考虑重新编写代码了。

2．10学习与重新学习：温故则知新，要多学习SAS，并且经常复习以前学过的文档。

2．11先放一放：如果一个问题你编了很久代码也没能解决，那么如果时间还宽余的话，可以试着先放一放，然后再回来想这个问题时，会有新的方法或观点来解决这个问题。不然的话可能会浪费很多时间，有时候可能只是哪一句话少写了个分号。

2．12反思一下整个解决方案：当debug完成后，我们要反思一下正确的程序应该是怎样的，你如何才到编出这样的程序，问题是如何识别的，问题处

理的过程是如何处理的，你是否依赖于经验，直觉，文档或其他资源，这些资源哪一个最有效，你遇到过哪些错误，哪些不同的逻辑，设计思路，问题表述可以让这

些问题在以后的编程中更少出现。对于解决问题的过程和日志我们最好做一个方案记录，在以后回顾和使用时非常有用的。

2．13问一下我是否修正了真正需要修正的东西：成功的debug是那种修正了真正的BUG，而不是其表像。我们要有时更要注意分析一下BUG出现的原因而非BUG本身。

2．14 有时候只是SAS的错

SAS有可能因为一个简单的错误报一大堆错误或警告，也可能SAS本身有着BUG。另外当程序运行很长一段时间后可能会出现一些莫名其妙的错误，这可能是内存问题引起的。最后SAS不能识别逻辑错误。

3关于debug工具

这里列举了很多可能用来debug的工具和选项，例如：SAS日志，系统选项，宏变量，宏，数据步及其DEBUG工具，以及过程步相关的选项与dictionary表和视图等。这些都比较简单，我也就列一下，以后会更详细地讲解

3．1系统选项

有些系统选项在配置文件里，也即是一些默认选项，例如DATE，CENTER，OBS等。然后就是系统层面的选项，这些选项我用得很少，不是很清楚，大概列一下吧：

另一类型的选项是MACRO选项，这个以后我们将会详细讲述一些非常有用的选项，以及如何使用这些选项进行DEBUG的。

3．2 SAS日志

对于一位程序员来说，日志对于DEBUG实在是太重要了，因此我们要经常查看日志，检查日志中的错误、警告以及记录。重新审查你的代码，以及记录字

符类型与数字类型的转换，识别创建的缺失值，识别未初始化的变量，描述输出SAS数据集的大小，描述外部数据源，以及PUT、%PUT的输出结果，以及其

它SAS宏选项(如SYMBOLGEN，MPRINT等)的输出。