The style of your coding can be almost as important as the actual code itself. Of course, the most important aspect of any program is its ability to perform the task expected of it; but secondary to that is the simplicity with which it can be read and understood by both yourself and other programmers. Coding style covers a range of things including layout, naming, and choice of statements.
Many popular elements of style are simply common sense, and others are very much personal preference. But if you work in a development team with a number of members, you will find great benefits to be had by standardising on a common set of style elements. If style makes the code more easily readable, then a standard style makes any team member's code instantly more readable to the other team members; and new team members will get up to speed more quickly if they only have one style to get used to.
I don't know of any references for SAS style guides, so I've developed my own. Having first used SAS in 1983, I've had many years in which to develop something good - perhaps even perfect! But that's not how programming styles develop and get used. At each client that I visit, I will generally find existing code with one or more elements of consistent style. In these cases I will make sure that the code that we produce for the client adheres to those same standards (unless I can provide a good justification to the client for changing them).
So the style recommendations that I will present in this and future issues of NOTE: will be simply recommendations. They must be interpreted and applied to your particular development team's needs.
So, let's start with one common sense style element, and one of my personal preferences.
Use comments
Place comments in your code. But make the comments useful instead of stating the obvious.
Place a comment block at the top of the program that provides a summary of the program's intended functionality. It is commonly a good idea to document the original author and date, plus the date and author and reason for any modifications to the code.
Document sections of the code that are not obvious in their intent. Comments regarding why something was done are typically more useful than those that say what is being done. Usually the latter is obvious, but it's the former that really reveals the hidden secrets.
One statement per line
Now this is a contentious one! Place no more than one SAS statement on each editor line. And if you can't fit a long statement on a single line, split it across several.
So, as an example, an IF statement should be on one (or more) lines, and its associated conditional code should be on second or subsequent lines. Remember too that DO is a statement. See below:
if 1 eq 0 then
moon = 'cheese';
if 1 eq 0 then
do;
moon = 'cheese';
clouds = 'marshmallow';
end;
Using no more than one statement per line has a number of advantages, including:
- Easier for the syntax checker to highlight statements with syntax errors
- Easier to add do-end blocks later if necessary
- Reduces density of functionality, making the code more readable because it's in smaller chunks
Style is obviously a personal thing. Write a comment to let us know what you think of our suggestions, and let us know your preferred style (and the reasons you choose it).
