DRY Principle

Don't Repeat Yourself. Wherever you find yourself writing the same bit of code over and over, turn it into a parameterized macro... or for scalar-like functions, use PROC FCMP to build a custom data step function that can be re-used.

By factoring out re-usable chunks of code into macros or fcmp functions, you make it easier to:

• Do the same thing again in a different context through re-use
• Maintain your existing programs (you only have to change the code in one location)

Sometimes less is not more!

Don't be afraid to put in that extra line containing the word run; at the end of your data step, or that quit; at the end of your proc sql, or even spreading out that proc means step across 2 or 3 lines instead of cramming it all on one 150 character line. Fine, it's your code and right now you know what it does but one day someone else is going to read your code and...

...it is much easier to write code then it is to read code.

Don't make them devote that extra bit of thought power to fill in the missing blanks. Write code as if you are writing it for somebody else to read. And make it as effortless as possible for them, because they're already trying to balance 12 other things in their head without the added difficulty of mentally adding in your missing end; statements.

When I read other people's program, things that help me most in understanding their codes are: - A detailed header with good revision history - Indentataion - Comments, especially if that section of code is a little bit tricky

I always type all SAS keywords in all upper case letters and all my variable names in either all lower case or in a mixed case for LongMultiWordVariableNames for easier reading and comprehension. Not all of us use the editors that try to color code certain key words (besides those aren't 100% correct). I learned this using other programming lanuguages & editors.

Consistent

• Indentation
• Use of upper & lower case (i.e. all keywords in lowercase, variables in upper/camel-case, macro-language code in upper-case - whatever you choose - just keep it consistent!)

Program header and revision history.

Detailed comments where appropriate.

Use of macros - don't wallpaper code!

Always replace tabs with spaces ( helps viewing code in other viewers).

When defining parameters like data=, out=, filevar=, which all are name/value pairs, place the = against the parameter name. That distinguishes options without = like nodupkey from those which must have the =. It helps me remember the various bits.

use white space to align logical / consistent code (not just do and end)

place "non-executable code" together (probably near the beginning) of a data step

take advantage of sas variable lists wherever possible, but document to clarify (don't you hate long lists of variables in a single column that runs over more than a screen, and is mostly repeated later in the prog!?)

Consider a spell checker: place the open-bracket right next to the function name [ sum( a, b, c ) and not sum (a,b,c) ]

The same for array references

In a block of code which are mainly assignments, align the =

Try to have a blank before each word of code (ok libname.memname cannot have that blank before memname, but that's the kind of exception that proves my rule;-)

Use enhanced editor abbreviations to simplify inserting block comments and prog headers - when it is the "easy way" it becomes the norm. (imho)

In SQL adopt the code layout standard used by SAS when you describe an sql view. The main theme of this is to separate keywords on the left from the lists (variables, tables, conditions, etc) on the right.

For comma-separated lists, like sql columns and macro parameters, where there are more than a few parameters, make continuation lines start with the comma, rather than ending the "unfinished" line with the comma. When "continuations start with comma" is your standard, it is very easy to check all commas are present, and very easy to delete/insert extra lines.

For code reviews, take time to print programs well - use something like word, with it's linenumbers (it is defined in page-layout, but make its font smaller) and have the original filename-with-path in the header, datetime in the footer (even better than a version number). Force wide lines to print on one, or split them in the original. After opening the sas program in word (with no colouring), paste the code from the enhanced editor over the program in word. Then you still have the path-name in the header from the word-open, but you get the syntax color and format highlighting from sas enhanced editor. Make sure the last line number in SAS is same as last line number in Word, and find/fix the line that is too wide (comments are easy to change to arial, but that doesn't suit code).

The more attention you pay to making your code readable, the more you'll be thanked by th eprogrammer who has to support it through problems (caused by bad data, or miss-use of course, you'll have no bugs in well presented code ;-) because attention to detail often highlights the bug before it is even tested!

just my opinions PeterC