Do you practice safe SAS?
The below is a short abstract from Veramed’s Good Programming Practice guidelines. For the full guide please download using the link on the right.
The purpose of this Guideline (GUI) is to provide guidance for good programming practices (GPP) for analysis, reporting and data manipulation of clinical data in health and life sciences organisations. This guidance is primarily aimed at programming in SAS, however the principles of GPP also apply to other languages such as R and Stata. In addition, although this is not produced with SAS macros in mind, the same principles apply to macros too.
We often have to update existing programs to add new rules, copy programs from one study to another, and take over programs written by others. The guidance aims to show how to produce well structured and well documented programs so that they are easy to read and maintain over time. It is meant to be applicable to all programs, and hence all programmers regardless of experience. Specific rules may be of more use to novice programmers, but applying the principles should be in mind for experienced programmers and mentors.
Log File Checking
As part of development and validation practices, it is often mandated that the log file generated is checked to ensure that the program has executed in the correct intention. Many companies may have their own automatic log file checking utilities to aid in this, and there are many examples of such tools in widely available papers. “ERROR” and “WARNING” in logs should normally be avoided. There are sometime exceptions to this, such as warnings that are output from statistical models that do not have enough data. Ordinarily, any warnings that are deemed acceptable are documented. There are also some specific “NOTE”s that can indicate a problem. The common “NOTE”s that should normally be avoided include those relating to “repeats”, “more than one”, “uninitialized” and “referenced”.
Also, any user defined checks that have been added, such as from defensive programming, should be checked for in the log and followed up on. A company-specific naming convention for user defined checks can aid in this, so the specific string can be searched for within the log. Examples of such conventions include “ISSUE:”, “USER:”, and “ALERT:”. Avoid the use of user-generated errors and warnings labelled “NOTE:”, “WARNING:” or “ERROR:”, as these may make it difficult to find genuine problems when searching the log.