Do SAS coding "best practices" exist?

Question

At work, we develop a lot of our applications in SAS, from start to finish. One of the problems with this approach is that SAS is a very verbose language with very few language constructs; there is limited support for variables, very limited support for basic functions, and no such thing as classes. They have a concept called "macros" which essentially text substitution; you define a macro, and on invocation, it simply drops in the content of the macro.

My question is, is anyone familiar with "best coding practices" for use in developing SAS applications? Are there software design patterns for SAS? I've gone through Code Complete, and some of what he writes is applicable to SAS, but much of it is not, as the concepts don't exist in SAS. Can anyone give recommendations for writing maintainable, well-designed SAS code?

Answer 1

I've been on the user-end of a few SAS systems, and quite frankly your description doesn't surprise me one bit. I wound up doing a fair bit of gap programming, to pick up slack left by the primary team, who reported that the SAS code they had was difficult to edit or debug.

Given the hindrances you mention, the best practices arise from recognizing the system's limitations and enforcing a language-level separation of concerns. Specifically:

1. Comment first, Code Second, Comment Last If you're doing OOP TDD, you can jump right in and start coding a prototype, then throw on your tests, and then refactor to cleaner code. You can't do that in SAS. Instead, decide what you want your code to do BEFORE you write it. Then write the code. Then go back and edit your comments to make sure they're accurate.

2. Embrace the language features. Macros seem like an excellent way to share simple code blocks between programs, either as connecting to particular data sources or performing distinct functions. Not as good as a proper function call, but better than nothing.

3. Don't make SAS do what other technologies can do better. If you're sending data to SQL server and need to archive the table, let SQL server handle that. If you're populating data as options for a client-side program, send your rows to a common format like XML and let the client-side program worry about its internal segmentation.

4. Don't try and force a model that SAS doesn't support. Without classes, you can't do OOP, so don't. SAS is closer to a set of distinct scripts or old-school mainframe programs anyway.

5. Simple is better than complex. Your SAS programs, if possible, should only do one thing. Pull the data from the client systems. Calculate the statistics. Store the calculated data. Format the calculated data as a report. Each of those steps should be a SEPARATE program file, even if you have to force them into one-time-use macros to do it.

6. Don't be clever. SAS is an agnostic, meta-language that pulls from a polyglot of data sources and exports to a byzantine array of formats. Which is all well and good if you need to access some obscure or legacy format, but is just asking for trouble if you jump to SAS's internal features without, at a minimum, leaving room for the data source to be optimized to produce your data quicker.

7. Don't be everything. SAS seems like an excellent tool for enterprise-wide data aggregation and analysis. But the same features that make it so worthwhile for that make it horrible for something like an email program, or a client-side custom calculator.

I haven't worked with SAS directly, or else I'd give you better specifics. But the aggravation that SAS has caused me with what I have seen has left me with a pretty firm opinion that SAS is a niche language, and shouldn't be used outside of its niche. There's nothing wrong with being a niche language -- RegEx and XSLT are both niche languages, and they're two of my favorites -- but it's a PHB-smell when a team is told to "use SAS" for everything.

Answer 2

This is tough to answer in the abstract, since SAS is such a huge product you could be talking about GUI applications, ETL routines, risk modeling applications, and probably other things I'm not thinking about.

That said, some googling will turn up this classic toungue-in-cheek paper: Programming For Job Security Revisited: Even More Tips And Techniques To Maximize Your Indispensability (pdf).

That offers an excellent guide to what should be avoided.

If your applications are ETL-ish at all, you might have a look at this blog post I wrote a year ago.

Answer 3

Yes, best practices do exist and are widely known among practitioners. (Of which I am one). Some are being written down by PHUSE on their wiki. http://www.phusewiki.org/wiki/index.php?title=Good_Programming_Practice_Guidance

I think in fact SAS is very OO. But the objects are data tables. They hold metadata, and can be manipulated. For a more formal view you could read 'programming with data' by Chambers for many of the same design goals and justification for objectifying tables.

1 proc step

SAS has two parts -- the high level - domain specific - procs for analytics and most every Statistical modelling. These have (yes, verbose) interfaces. But good defaults and easy to get answers. For example try to program even a simple factorial ANOVA in Fortran, C, C++ or Java.

2 data step

And part two is a low level data manipulation language that predates SQL that is admittedly sequential but, very fast. It has the property that a program you write will run on any size dataset -- limited only by your disk space - or number of tapes if you have tapes. This differs from all the languages I mentioned and also from most Stats Packages too. (e.g R, without the enterprise big file packages from Revolution Analytics).

The macro language fits in there.

3 However

New tools are here and these are the hash object which can persist and the proc FCMP which can encapsulate code data step and proc step. It can pass values or matrices back to the caller. See my paper here for more info and references and an assessment of hash objects in a real life case study.

http://www.phusewiki.org/docs/2012/PAPERS/CS/CS05.pdf