Basic Program Structure/Flow

[pchappus]

Anybody have some materials / advice on creating a program and how to structure it?

For example, I'm working on a program that is currently 600+ lines long and it might end up being 1000 when it is all said and done. It has various data steps, proc sqls, macros, etc. It creates 40+ tables, some temporary, some not. I still learning SAS and haven't really seen anything on structure a long process.

I've started creating user defined macros in the program to kind of help structure what that series of code is doing. Do people tend to do this? I've been thinking of going back and doing this for other steps that I didn't include in macros. Should I create a program for each one of these macros and then %INCLUDE them in a main program that calls them all and then runs the macros?

Any advice would be great! 

Thanks,

[VDD]

Are you a BA?  Don't break what works.  sometimes people write long converted programs to do very long converted process's.

[ballardw]

---

@pchappus wrote:

Anybody have some materials / advice on creating a program and how to structure it?

For example, I'm working on a program that is currently 600+ lines long and it might end up being 1000 when it is all said and done. It has various data steps, proc sqls, macros, etc. It creates 40+ tables, some temporary, some not. I still learning SAS and haven't really seen anything on structure a long process.

I've started creating user defined macros in the program to kind of help structure what that series of code is doing. Do people tend to do this? I've been thinking of going back and doing this for other steps that I didn't include in macros. Should I create a program for each one of these macros and then %INCLUDE them in a main program that calls them all and then runs the macros?

Any advice would be great! 

Thanks,

---

First: 1000 lines don't really mean "long program"

if a process is moderately long I tend to divide into functional areas and create separate self-contained program files for each function.

Typically those would be 1) read the data (if external file is source); 2) clean or verify that the data is useable (no missing values for key variables, variables in defined ranges, all the groups such as organization that should be present are); 3) Restructure data or add variables that are needed for analysis; 4) analysis likely creating data sets for: 5) reporting.

Pieces that are likely to be needed in multiple parts of the such a library definitions, formats, informats, macros (cautiously) would go into a program file to include at the top of each of those (or make sure it is run before any of them).

Those may have sub-parts such as reading from external files from multiple sources likely requires a separate read and clean step and likely means that the restructure step means combining data.

If I have to go back to modify a variable or such then rerunning the dependent pieces are relatively easy.

One strong hint if when you get to the "report" phase, such as would appear between ODS <destination>; Ods <destination> close; statement really shouldn't have any data manipulation. That keeps the output coding much cleaner.

[SASKiwi]

Splitting off macros into separate programs is a good idea. A really good way of handling these is by setting up an AUTOCALL macro library. See here for details:

https://documentation.sas.com/?docsetId=mcrolref&docsetTarget=n1o5fkxq0gqdpcn1xs3ksdks69tf.htm&docse...

The main advantage of an AUTOCALL library is you don't need to %INCLUDE the programs. SAS does that for you automatically.

I've built some pretty large SAS applications and I always use AUTOCALL macro libraries. They help keep your SAS applications structured and tidy as well.

[Reeza · Accepted solution]

Quick summary:

I break my programs into logical bits.

1. Data import
2. Data cleaning
3a. Labels, formats
3b. Macros needed
3c. Style templates needed
4. Analysis
5. Reporting

I label programs P001 - Program name is long name.sas
P002 - blah blah

This means programs sort in order.

I also set up several folders:

rawData
cleanData
SAS PRograms
SAS Data sets
SAS output
Deliverables
References

And others as needed.

Other best practices:
1. Description of program at top of program
2. Comments - make them context oriented, why are you doing this? Assume the user can read SAS code, but needs to know why you're doing something. Eg
Recoding variables to 0/1 from Y/N to allow for quick summarization in proc means.

3. Look for multiple similar steps, 3 data steps back to back can likely be combined.


That's just a quick starter. If you're looking for more advice, please search on lexjansen.com for best practices guides.