Use Title and Label Statements to Document SAS Code

 

“I don’t document my code because if you really understood the language, it should be obvious.”

– Bob

Bob is an arrogant little prick.

Here are just a few reasons to document your code.

1. Other people may need to modify it because, despite your assumed brilliance, there may be other people in the universe capable of maintaining your code when you get a promotion, take another job or get your sorry ass fired.
2. Six months from now, you may need to look at this code again. After 11 other projects have intervened, you’ll be trying to figure out what the hell the prev_grant_yrs variable was supposed to measure. Every time I add comments to a project, I say to myself, “Future me will thank me for this.”
3. If you use Title and Label statements, there will be additional clarity not just for you as a programmer but also for the users.

Here is an example

This comes from a longitudinal analysis of a vocational rehabilitation project. There are only two comment statements in this snippet, however, there is a LABEL statement which explains that the prev_grant_yrs variable is the number of years a consumer was served under the previous grant. There was a significant change in operations in the current grant cycle, but when this five-year cycle started there were a number of people already on the caseload who had been determined eligible under the previous administration.

data by_year ;
set mydata.vr2018 ;

** USES YEAR FUNCTION TO GET THE YEAR OF INDIVIDUAL PLAN OF EMPLOYMENT ;

*** AND OF APPLICATION TO THE PROGRAM ;


ipe_year = year(ipe_date) ;
app_year = year(app_date);


if ipe_year ne . and ipe_year < 2008 then prev_grant_yrs = "5+" ;
else if ipe_year < 2012 then prev_grant_yrs = "2-4" ;

  else if ipe_year > 2011 then prev_grant_yrs = "0-1";

LABEL prev_grant_yrs = "Years Under Previous Grant"
ipe_year = "Year IPE written"

app_year = "Year applied"

;

The first procedure, I simply wanted to get a closer look at the people who had been getting services for more than five years under the previous grants. It’s important to add that second title line so readers know this isn’t ALL long-term consumers but those who had been long-term users coming into the current grant cycle.

TITLE "Check long-term consumers";

TITLE2 "Getting services 5+ under the previous grant" ;
proc print data= by_year ;
where prev_grant_yrs = "+5";
id username ;
var ipe_date app_year prev_grant_yrs ;
format ipe_date mmddyy8. ;


The second procedure, I wanted to see how consumers served in the current year were doing. Why do I have grantyear as a variable in the VAR statement when it is clear from the WHERE statement that only people from 2018 will be included?  Because the person who gets the output won’t see that WHERE statement. Just having “current year” in the title is not enough because next January someone looking at this might think it was for 2019.  I could have included 2018 in the title, but including it as a variable on the output both acts as a validity check for me and lets the user, my customer, know that the data are correct.

TITLE "Current year consumers" ;
proc print data=by_year ;
where grantyear = 2018 ;
id username ;
var grantyear status status_type ipe_year;
format ipe_year mmddyy8. ;


A few of the individuals served by this project did not have an Individual Plan of Employment. I wanted to see if the people missing an IPE just hadn’t had time to complete it yet or if they never came back and did it. An IPE is the first step in getting project services, so, if they had a missing date for a year or more than they had just dropped out. Again, the second title line tells the users what I’m trying to do here.

TITLE "IPE YEAR by Application Year";
TITLE2 "Note: Missing IPE consumers had ample time to complete IPE";
proc freq data=by_year ;
tables ipe_year*app_year/missing ;

So, you get the idea. Elegant code is nice, correct code is essential.

You know what is essential?

A young person once asked me,

“No offense, but why are your services so much in demand? It’s not as if there aren’t a lot of people who can do what you do.”

Okay, first tip, young people, when you find yourself saying, “no offense” you should probably just stop talking and then you definitely won’t offend anyone. Actually, I was pretty amused. It’s true that lots of people can do frequency distributions, if-then-else statements and cross-tabulations (although, in my defense, that’s not ALL I did on this project).

One essential skill is make your analyses easily understood by your co-workers and customers.

As a wise person once said,

“Mystery novels should be figured out. Code should be read.”

---

Wonder what else I’m writing these days?

You can get A Different Kind of Textbook, our family group text, for $2.99 as an ebook.  We definitely are a different kind of family.