I have a question regarding your approach to complex project / long SAS code files.
One problem that I frequently encountre with long SAS projects, is that the code becomes so long that it becomes difficult to come back at a later stage and just jumt into a specific pasrt and debug it or change it...
Commenting the code is something that I always use, but still, this becomes impractical when the code is very long...
I wish that SAS could add the option of Bookmarks into the code so that it would easier to find the part I want to go to and debug from there.
HOWEVER, my approach now is to split the code, so I have one file that prepares the main dataset, and then several other .sas files with code that basically built from the main dataset to give a specific part of the solution.
This is not a straight forward solution as you can imaging, my question to you is: Is there a code/way to excute the code in a .sas file from another .sas file
What I am trying to do is something somilar to %include but that would excute standard sas code rather than a Macro code.
So here is what I want to do
some code to excuse data.sas which prepares the main dataset
.
.
.
.
code here to process the data generates
..
.
.
I am also interested to hear what you do or if you have a different approach to long/ complex sas code files
Thnak you
%INCLUDE() runs whatever code is included, whether it's SAS code, formats, functions or macros.
I typically use the approach there but my code is organized into sections based on project.
Formats & Functions each go into their own file.
Macros - it depends, depending on the type will either be their own file or multiple in one. If it's very project specific, they'll be in one, if they're more generic they're in a single unique file.
This approach allows me to re-use macros/formats/functions easily.
I then break my main programs into:
Data Import
Data Prep/Cleaning
Data Analysis
Reporting & Graphs
%INCLUDE() runs whatever code is included, whether it's SAS code, formats, functions or macros.
I typically use the approach there but my code is organized into sections based on project.
Formats & Functions each go into their own file.
Macros - it depends, depending on the type will either be their own file or multiple in one. If it's very project specific, they'll be in one, if they're more generic they're in a single unique file.
This approach allows me to re-use macros/formats/functions easily.
I then break my main programs into:
Data Import
Data Prep/Cleaning
Data Analysis
Reporting & Graphs
I concur with what Reeza said about breaking it up with some of my own caveats.
%include works for anything: don't think of it as macro coding because it isn't (despite the % in front).
For complex coding, I prefer to use %include and data step vs macro. Why? Easier to debug. An example:
data _null_ ;
file someTempFile ;
put 'data test;'
/ 'set sashelp.class;'
etc.
run;
%include someTempFile ;
What you get is standalone sas programs that can be tested in isolation vs macro stuff. When macro gets really complex, it is very hard to debug. Using the put staments, you achieve the same processing cost but at leat you can see what is happening.
Split it, isolate it, make it something you can easily decipher and test.
Also, adopt documentation standards. See an example on sasCommunity called SaviDoc. File link is gone (I can send you it) but the standards are listed. If you follow them, you can create your own bookmarks by merely parsing your SAS code.
I normally try to break up the problem into logical units and to implement these as self contained SAS programs.
This allow to test each program individually as well as to run the whole project either via a master.sas or even better via a scheduler which then also allows for parallel run of programs with full control over job dependencies.
Thank you everyone for the responses which are highly appreciated.
@Patrick could you please elaborate on using a "scheduler" ? I am interested in knowing how you use this
Kind regards
Here is a useful link that describes the various ways SAS jobs can be scheduled. It is a very large topic so don't be put off by this. Scheduling is an essential part of any SAS Production environment.
Also for managing large and complex SAS applications, using version control tools is also very helpful as you can compare changes made between program versions and easily follow the complete history of your code development.
Thank you for the reply
What version control tools do you use / recommend please?
Kind regards
Use Git. I wouldn't even bother with others (or even looking at alternatives) unless you are required to use something else.
Git is also integrated with EG so that helps a lot as well.
You might find this thread on Git helpful https://communities.sas.com/t5/SASware-Ballot-Ideas/enable-non-local-git-server-integration/idi-p/31...
@ammarhm - Regarding version control tools - I always recommend checking out those that are already used in your organisation. Perhaps there is already a preferred enterprise tool that is already setup and all you have to do is start using it. That is the case where I currently work. It just so happens that the tool is Microsoft Visual Studio with MS Team Foundation Server. It works really well with SAS programs and integrates nicely with SAS Enterprise Guide.
I am sure there are many other VC tools that work equally as well but using an existing tool in your company is just so much easier.
Modular programming is definitely a big help to keeping things organized. You can use %INCLUDE statement for modules (as others have pointed out, it's not related at all to the macro langauge), or macros. I tend to use macros for modularization, because the definition I learned for a macro was "a parameterized unit of code." That ability to pass parameters makes it easier to develop, test, and re-use.
Ed Healton has a nice paper on an approach to top-down structured programming using macros:
http://www.lexjansen.com/nesug/nesug01/at/at1010.pdf
When you do it well, you can end up with a nice high-level outline of macro calls, which make it easier to understand the structure / flow of the of the code wiout stating at pages of code. Ed mentioned to me at one point that his rule was "if you can't read the whole module in a single screen, consider splitting it into multiple modules."
So you might end up with:
%setup()
%ReadData(file=)
%AnalyzeData(...)
%EmailResults(..)
%CheckLog(...)
And of course each module above would have sub-modules.
In Enterprise Guide, you can use the process flow view to visually arrange the modules (where each module is a linked .sas file storing a single macro definition).
I don't always use this approach to the extreme, but it's handy to keep in mind for complex problems. And when I use it, I rarely regret it.
--Q.
Thank you everyone for the suggestions and useful answeres
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
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.