10-31-2012 02:08 PM
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.
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;
if cust_acct_nbr>0 then output tag_w_account;
if cust_acct_nbr<=0 then output tag_wo_account;
Or this code (which does the same thing as above):
create table tag_w_amount as
create table tag_wo_account as
Maybe I should label it SELECT, because it selects rows from the tables?
Just wanted to see what other people's thoughts are.
11-01-2012 11:47 AM
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.
11-01-2012 12:02 PM
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.
11-01-2012 12:50 PM
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.