Desktop productivity for business analysts and programmers

Opinions on EG best practices - code location and relative paths

Reply
Contributor
Posts: 24

Opinions on EG best practices - code location and relative paths

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.

Contributor
Posts: 24

Opinions on EG best practices - code location and relative paths

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.

Super User
Posts: 3,233

Opinions on EG best practices - code location and relative paths

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.

Trusted Advisor
Posts: 2,114

Opinions on EG best practices - code location and relative paths

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

Frequent Contributor
Posts: 90

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

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.

Community Manager
Posts: 2,882

Opinions on EG best practices - code location and relative paths

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:

relative.png

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-sa...


Chris

Ask a Question
Discussion stats
  • 5 replies
  • 394 views
  • 0 likes
  • 5 in conversation