topic Re: Standard way of describing what SAS programs do? in SAS Programming

Standard way of describing what SAS programs do?

adamhyman — Wed, 31 Oct 2012 18:08:37 GMT

I like using Enterprise Guide to spread out my code, so I can see how the data moves.

I can easily see the order in which code must be run. If I change something, I can easily see which programs must be re-run.

When I create a new piece of code, the name give to it is: Program, Program1, Program2, Program3 etc.

Is there a standard way of describing what SAS programs do, so that I can come up with a descriptive name to name the programs?

This would make it easy to get a high level understanding of what someone else's code does without opening each program.

For example:

Code that merges two datasets, with proc sql or datastep, could be labeled: MERGE

Code that transposes could be labeled: TRANSPOSE

Code that appends tables could be labeled: APPEND

How would I label this code?

data tag_wo_account tag_w_account;

set tagdata;

if cust_acct_nbr>0 then output tag_w_account;

if cust_acct_nbr<=0 then output tag_wo_account;

run;

Or this code (which does the same thing as above):

proc sql;

create table tag_w_amount as

select *

from tagdata

where cust_acct_nbr>0;

create table tag_wo_account as

select *

from tagdata

where cust_acct_nbr<=0;

quit;

Maybe I should label it SELECT, because it selects rows from the tables?

Just wanted to see what other people's thoughts are.

Thanks!

Adam

Re: Standard way of describing what SAS programs do?

ballardw — Thu, 01 Nov 2012 15:47:10 GMT

You may want to be a bit more descriptive than just MERGE such as which sets or type of merge.

Your example looks like somthing I might call SPLIT CUSTOMERS because you are taking one set and splitting it into two. SELECT would be either reducing variable or reducing records in my mind, which is why I would be a little more descriptive.

Re: Standard way of describing what SAS programs do?

Astounding — Thu, 01 Nov 2012 16:02:43 GMT

You are looking at this from a programmer's point of view. Might it be important for a nonprogrammer to understand the flow? Do you ever have to explain to your internal customers what your program does?

As you noted, there are steps where you could use entirely differernt programming techniques to accomplish the same purpose. I would switch to a functional point of view, with a little more detail. Example:

SPLIT OUT BAD CUSTOMER NUMBERS

I wouldn't care whether it was done with a MERGE or SQL. As you can see, I don't mind typing a bit more (yes, I am willing to use 32-character variable names).

I'm not sure this is any different from ballardw's suggestion ... just another vote to move in that direction.

Good luck.

Re: Standard way of describing what SAS programs do?

TomKari — Thu, 01 Nov 2012 16:50:06 GMT

And another vote with the group. Generally, in documenting software functionality, a good approach is VERB NOUN(s), where:

VERB should be a specific action done by the software (Sort, Merge, Display, Report ...). Don't use "general" terms like Process, as they don't provide any insight.

NOUN(s) should be objects that make sense in your business terminology (Customer, Part Number, Financial Code).

So you can see that "SPLIT OUT BAD CUSTOMER NUMBERS" is a very good name for the process. As an additional benefit, this will tend to drive your programs towards implementing single functions that can be clearly described, which is beneficial for ongoing maintenance. When you find yourself using more than one verb, or resorting to verbs like PROCESS, it's time to start thinking about whether your program is a muddle of coincidentally linked functions.

Tom