Good Programming Practices

Always print (or save) the log as well as the output from a program and keep them together! What good is the output if you don't have a clue what created it?

Read the log for error and warning messages! SAS (and other languages) will try to resolve problems before stopping the program. Many warning messages cannot be ignored and in fact show that your program is not working correctly.

Check your output! Just because you didn't get any error or warning messages doesn't mean that your program did what you thought it would. Check any calculations! One important thing to note is the number of observations going into your program and the number of observations coming out of your program. If they are not the same, do you know why?

Document your code ! Why you recoded a variable may be obvious today but might not be 6 months from now or to another person on your project. An easy way to document your SAS program is to put your comments in the form /* put comments here */ at the end of the line of code that your are commenting. In addition ,use a documentation box: at the beginning of your program such as the one below. This will enable you to find out what your program does without reading hundreds of lines of code.

********************************************************************************

*PROGRAM NAME: readraw.sas

*DESCRIPTION: read raw data into a SAS file

*INPUT FILES: rawfile.dat.gz

*OUTPUT FILES: sasfile.ssd01

*WRITTEN BY : Cindy Mitchell

*DATE: 09/17/97

*MODIFICATIONS: 09/20/97 C. Mitchell created century month variables
for all dates

*****************************************************************************;

Use variable names that make sense.! If it is a birth date use a variable name such as bdate or a common acronym such as dob (date of birth).

If you are working on a large data set, limit the number of observations going into a test program. This can significantly reduce processing time, resource needs and can make debugging your program much easier.