zz: Structuring SAS Programs

Structuring SAS Programs

The primary aim in writing SAS code is to get a job done. But the job is not just to produce some output. You should structure your SAS programs:

• make finding errors as easy as possible

• make the code easy to understand later by yourself or someone else

• document the time and stage of the analysis

• document data edits and corrections

Most projects have an initial data cleaning phase, followed by an analysis to write a paper. After the paper is submitted, there is a delay until the referee reports arrive, followed by another analysis with revisions. Interruptions of weeks or months in a project are common—write your code to make it easy to pick up later.

Advice:

1. List program name, date, author, and revision date(s), and what the program does at the top. Use comments to break code into sections.

2. Edit the data and create new variables in a single data step at the beginning of the program, as far as possible. This makes it easy to find and to correct problems.

3. Use as few data steps as possible. Data steps are the most confusing part of a program.

4. Use comments to explain data edits and identify data problems. Hard code all data corrections in these programs. If there is email or other documentation, include this as comments in the code, so you don’t need to search your mail files later to figure out what happened.

This advice also applies to a collection of programs written for a project:

1. Number the programs within their names as you write them: PlanB_01.sas, PlanB_02.sas, etc.

2. Do all the data editing and creation of permanent datasets in the first program—no analysis. Hard code all data corrections in these programs. Include email correspondence as comments in the code.

3. Perform analysis in later programs that simply call the permanent datasets. Analysis programs should only create temporary datasets

Multiple versions of the same data invite trouble.