Tag Archives: Kirk Lafler

Kirk Lafler Shares 25 Coding Techniques!

25 Best Practice Coding Techniques for SAS Users By Kirk Paul Lafler, Software Intelligence Corporation

As SAS software becomes increasingly more popular, best practice coding techniques and guidelines become ever so critical. SAS software provides users with a powerful programming language for accessing, analyzing, manipulating, and presenting data. This tip addresses useful coding techniques for all operating system platforms.

  • After running a SAS program, immediately review the SAS log for notes, warnings, and error messages. Avoid turning off SAS System options that turn off SAS log notes, messages, and warnings.
  • Turn on the SOURCE2 SAS System option to display included source code on the log. Best practice coding techniques should mandate inclusion and display of any and all information that is available during a SAS session.
  • Considering procedures like PROC SQL and PROC REPORT for code simplification. Because multiple processes can be frequently accomplished in a single procedure step, I/O may be reduced.
    When a DATA step or PROC can do the same job, consider using procedures whenever possible. Procedures are tried-and-proven throughout the world’s SAS installations, testing requirements is considerably less.
  • Create user-defined format libraries to store formatted values in one place. User-defined format libraries have the added advantage of making programs easier to maintain since formatted data values are not hard coded.
  • Include RUN statements at the end of each DATA or PROC step (to separate step boundaries) to print benchmark statistics on the SAS log immediately following each step.
  • Document programs and routines with comments. In addition to the value associated with explaining program logic, comments should provide important information about complex code and logic conditions in a program. This helps to document important program processes as well as minimizes the learning curve associated with program maintenance and enhancement for other users.
  • Assign descriptive and meaningful variable names. Besides improving the readability of program code, it serves an important element in the form of documentation.
  • Construct program header information to serve as program documentation for all programs. The following example illustrates the type of information that can be added so others have a useful documented history.
  • Simplify complex code and operations into smaller, more manageable parts. By splitting complex code into two or more programming statements, a program becomes easier to read as well as more maintainable.
  • Specify SAS data set names when invoking procedures to help improve documentation efforts as well as preventing an incorrect data set from being processed.
  • Utilize macros for redundant code and enable autocall processing by specifying the MAUTOSOURCE system option.
  • Create macro libraries to store common macro routines in one place.
  • Create permanent libraries containing information from daily, weekly, monthly, quarterly, and annual runs. The type of libraries consists of scripts, SAS programs, SAS logs, output lists, and documentation of instructions for others to follow.
  • Create views based on user input to simplify and streamline redundant, complex and/or burdensome tasks. Consider creating views in a central view library to support maintenance and documentation requirements.
  • Code for unknown data values. This will prevent unassigned or null data values from falling through logic conditions.
  • Store informats, formats, and labels with the SAS data sets that use them. Informats, formats, and labels should be stored with important SAS data sets to minimize processing time. An important reason for using this technique is that many popular procedures use stored formats and labels as they produce output, eliminating the need to assign them in each individual step. This provides added incentives and value for programmers and users, especially since reporting requirements are usually time critical.
  • Construct conditions that would render data unusable and abort (or end) the program. This prevents unwanted or harmful data from being processed or written to a data set.
  • Test program code using “complete” test data particularly if the data set is small or represents a random sample of a large data set.
  • Set OBS=0 to test syntax and compile time errors without the risk of executing any observations through a DATA or PROC step.
  • Use the PROC SQL VALIDATE clause to test syntax and compile time errors in PROC SQL code.
  • Specify the NOREPLACE system option to prevent permanent SAS data sets from accidentally being overwritten while writing or testing a program.
  • Take advantage of procedures that summarize large amounts of data by saving and using the results in order to avoid reading a large data set again.
  • Add options that are frequently used into the SAS configuration file. This eliminates the time and keystrokes necessary to enter them during a SAS session.
  • Add statements that are frequently used into the SAS autoexec file. This eliminates the time and keystrokes necessary to enter them during a SAS session.
  • Source: 25 Best Practice Coding Techniques for SAS Users By Kirk Paul Lafler, Software Intelligence Corporation