topic Opinions on EG best practices - code location and relative paths in SAS Enterprise Guide

Opinions on EG best practices - code location and relative paths

JenHarper — Fri, 11 Nov 2011 16:32:31 GMT

I know that there will be opinions both ways on this, but I am curious to see what folks are thinking and why. So, the two topics are:

1) Thoughts about saving code within the EG project versus as shortcuts and saving the code as .sas outside the project

2) Thoughts about using relative paths for pointing to external files - such as external code (if we go that way) or external data sets, etc.

Opinions on EG best practices - code location and relative paths

JenHarper — Fri, 11 Nov 2011 16:54:42 GMT

I'll start by answering my own questions

1) Code location

At first we were embedding the code, but then I was offsite using my mac via remote desktop to run an unplanned fix to the code. I found I couldn't get to the code b/c EG was not on our server. After that we went to the practice of putting the code external so it was available in case we for some reason needed a way to run the code interactively (we are SAS programmers, not EG analysts so we are very comfortable with that). Since then we've loaded a copy of EG on the server so now even from my mac with VPN and remote desktop, I can log in and run EG projects no problem

My conclusion: If you have EG available in all your environments, keeping the code inside the program is the way to go as it prevents things from getting lost when you migrate environments and reduces the chances of accidental deletion/editing/moving.

2) Relative paths

My conclusion: Why wouldn't we - other than the chance you forget to migrate external files with it - and that is just making sure we have good attention to details. Okay, easier said than done, but we should be able to do it.

Opinions on EG best practices - code location and relative paths

SASKiwi — Sun, 13 Nov 2011 22:14:22 GMT

If you need ultimate flexibility in how you run your SAS programs and from what location you run them from, then I suggest it is best to avoid relative paths. However it is common practice for us to set up a global macro variable to define our application path like so: %let appdir = \\ourappserver\appdir1\appdir2; We then cascade this definition throughout all SAS programs in the overall SAS application so it sort of acts like a relative path. Then it doesn't matter from where you run your SAS application: SAS server, any desktop etc the programs always reference directory locations correctly. And if you want to switch between Production / Test / Development environments you just need to change one macro variable and the application then is re-pointed to the new environment.

Opinions on EG best practices - code location and relative paths

Doc_Duke — Mon, 14 Nov 2011 15:22:08 GMT

Jen,

On the code location. The best answer is "it depends". If the code is to be used by multiple projects, then storing it outside EGuide makes maintenance easier. If the code is project specific, then inside EGuide is fine. Another consideration is the editor. Like many who program a lot, I am rather fond of an editor other than the SAS provided one; if I want to use that editor, I need to keep the code outside of the EGuide project.

[The EGuide editor has actually gotten pretty decent. As I work in both the Unix and PC worlds, I prefer the consistency of EMACS.]

Doc Muhlbaier

Duke

Re: Opinions on EG best practices - code location and relative paths

hellind — Tue, 15 Nov 2011 08:35:28 GMT

1) Thoughts about saving code within the EG project versus as shortcuts and saving the code as .sas outside the project

I save my codes externally as different .SAS files. And heavily use %include in the main .SAS.

PROS: I primarily used EG. But when I need to run on my desktop version of SAS for Windows, I can migrate it easily from EG. Sometimes our corporate SAS Server which is shared by many departments can be very slow.

CONS: Without EG, there is no Link and it is not easy to visualize the link and order of codes: http://freepicupload.com/images/909eg_flow.jpg

This problem of visualizing the structure of the code will be gone after sometime when the user gets used to the project. For documentation, we draw a diagram of the code hierachy.

2) Thoughts about using relative paths for pointing to external files - such as external code (if we go that way) or externa

As SASKiwi as replied, I use global variable to define the path and libraries.

Opinions on EG best practices - code location and relative paths

ChrisHemedinger — Mon, 21 Nov 2011 20:17:28 GMT

EG 4.3 added an under-advertised feature for relative paths. You can store files such as SAS programs, and Excel and text files for import, in a folder relative to the EGP file, and when you move the whole collection around from machine to machine (or check in/out of a source management system) the files should all resolve.

First, enable it for your project with File->Project->Properties, select File References and the "Use relative paths" option:

Then you can have a file structure like:

C:\Projects\MyProject.egp

C:\Projects\programs\FirstToInclude.sas

C:\Projects\programs\SecondToInclude.sas

C:\Projects\data\ExcelToImport.xlsx

Assuming that you add the SAS programs by reference (not embedded) and import the XLSX file, this entire folder structure becomes "portable" -- you can lift it and drop it on another folder, drive, or machine and all should resolve without having to fix in Tools->Project Maintenance.

And you can make your code "relative folder aware" as well, using this tip:

http://blogs.sas.com/content/sasdummy/2011/07/11/how-to-assign-a-library-to-the-same-path-as-your-sas-enterprise-guide-project/

Chris