BookmarkSubscribeRSS Feed
adamhyman
Calcite | Level 5

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

3 REPLIES 3
ballardw
Super User

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.

Astounding
PROC Star

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.

TomKari
Onyx | Level 15

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

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 3 replies
  • 488 views
  • 0 likes
  • 4 in conversation