most recent 30 from http://www.runsubmit.com 2010-07-29T19:52:59Z http://www.runsubmit.com/feeds/question/169 http://www.creativecommons.org/licenses/by-nc/2.5/rdf http://www.runsubmit.com/questions/169/sas-coding-standards jay.l.stevens 2009-12-16T16:36:13Z 2010-01-13T08:30:26Z

<p>What are some useful and necessary coding standards that most, if not all, SAS programmers should adhere to?</p> <p>One suggestion/coding standard or principle per Answer. Vote up the answers you agree with.</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/170#170 jay.l.stevens 2009-12-16T16:40:12Z 2009-12-16T16:40:12Z

<h2>DRY Principle</h2> <p>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 <code>PROC FCMP</code> to build a custom data step function that can be re-used.</p> <p>By factoring out re-usable chunks of code into macros or fcmp functions, you make it easier to:</p> <ul> <li>Do the same thing again in a different context through re-use</li> <li>Maintain your existing programs (you only have to change the code in one location)</li> </ul>

http://www.runsubmit.com/questions/169/sas-coding-standards/171#171 unknown (yahoo) 2009-12-16T17:41:40Z 2009-12-16T17:41:40Z

<p>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</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/172#172 rick 2009-12-16T23:12:24Z 2009-12-16T23:12:24Z

<p>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 &amp; editors.</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/173#173 Chris Jones 2009-12-17T12:24:13Z 2009-12-17T12:24:13Z

<p>Consistent</p> <ul> <li>Indentation</li> <li>Use of upper &amp; 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!)</li> </ul> <p>Program header and revision history.</p> <p>Detailed comments where appropriate.</p> <p>Use of macros - don't wallpaper code!</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/188#188 Robert Penridge 2010-01-06T06:46:40Z 2010-01-06T06:46:40Z

<p>Sometimes less <strong>is not more</strong>!</p> <p>Don't be afraid to put in that extra line containing the word <strong>run;</strong> at the end of your data step, or that <strong>quit;</strong> at the end of your <strong>proc sql</strong>, or even spreading out that <strong>proc means</strong> 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... </p> <p><strong>...it is much easier to write code then it is to read code.</strong> </p> <p>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 <strong>end;</strong> statements.</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/202#202 PeterC 2010-01-12T16:30:31Z 2010-01-12T16:30:31Z

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

http://www.runsubmit.com/questions/169/sas-coding-standards/203#203 PeterC 2010-01-12T16:34:31Z 2010-01-12T16:34:31Z

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

http://www.runsubmit.com/questions/169/sas-coding-standards/204#204 PeterC 2010-01-12T16:40:06Z 2010-01-12T16:40:06Z

<p>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!?)</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/205#205 PeterC 2010-01-12T16:51:50Z 2010-01-12T17:32:39Z

<p>Consider a spell checker: place the open-bracket right next to the function name [ sum( a, b, c ) and not sum (a,b,c) ] </p> <p>The same for array references </p>

http://www.runsubmit.com/questions/169/sas-coding-standards/206#206 PeterC 2010-01-12T17:33:26Z 2010-01-12T17:33:26Z

<p>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. </p>

http://www.runsubmit.com/questions/169/sas-coding-standards/207#207 PeterC 2010-01-12T18:04:28Z 2010-01-12T18:04:28Z

<p>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;-)</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/208#208 PeterC 2010-01-12T18:37:56Z 2010-01-12T18:37:56Z

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

http://www.runsubmit.com/questions/169/sas-coding-standards/209#209 PeterC 2010-01-12T20:13:40Z 2010-01-12T20:13:40Z

<p>Always replace tabs with spaces ( helps viewing code in other viewers).</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/210#210 PeterC 2010-01-12T21:04:22Z 2010-01-12T21:04:22Z

<p>In a block of code which are mainly assignments, align the = </p>

http://www.runsubmit.com/questions/169/sas-coding-standards/211#211 PeterC 2010-01-13T06:52:30Z 2010-01-13T06:52:30Z

<p>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.</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/212#212 PeterC 2010-01-13T07:24:20Z 2010-01-13T07:24:20Z

<p>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.</p>

http://www.runsubmit.com/questions/169/sas-coding-standards/213#213 PeterC 2010-01-13T08:30:26Z 2010-01-13T08:30:26Z

<p>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).</p> <p>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!</p> <p>just my opinions PeterC</p>