Building the Better Macro:
Best Practices for the Design of
Reliable, Effective Tools
Till June 15 th … Chapel Hill, NC
Then … Philadelphia, PA
Premise and Scope
? Macro language is a powerful adjunct to the SAS
? Its flexibility is an asset
? Its flexibility is a liability
? Some self-imposed structure is needed
? To do the "right thing"
? To simplify coding and debugging
This paper presents a collection of design guidelines.
They  are not exhaustive  are "arguable" (e.g.,
"What?! No mention of function-style macros!!"
Well … no)
Reasons to Care (1 of 2)
%do i=1 %to &nDatasets.;
%let dset=%scan(&dsList., &i.);
%if &nobs. > 0 %then %do;
… ODS, PROC REPORT statements …
Seems harmless, but it loops, always displaying the
first dataset in the list.
We trace the problem to %dsetN, which set &I=1
Easily fixed (make scope of I in dsetN=local), but
irritating that we have to fix it
Reasons to Care (2 of 2)
proc print data=ae_miss;
title "Variables in CLIN.AE that
had all missing values";
The macro ran correctly, but left temporary datasets
and macro variables in the SAS session.
It isn't the end of the world, but it is sloppy coding.
1. Know When a Macro Is and Is Not Necessary
Macros are helpful and often essential.
Even well-designed and well-doc