Making your SAS code more readable


I have been programming SAS for a LONG time and have never seen much in the way of programming standards. For example, most SAS programmers indent DATA and PROC statements (I like three spaces). Most programmers do not like to see more than one statement on a line and most agree that there should be blank lines between program boundaries (DATA and PROC steps).

I thought I would share some of my thoughts on programming standards, with the hope that others will chime in with their ideas.

    • I like to indent all the statements in a DO group or DO loop. If there are nested groups, each one gets indented as well.
    • I prefer variable names in proper case.
    • I am not a fan of camel-case. For example, I prefer Weight_Kg to WeightKg. The reason that some programmers like camel-case is that SAS will automatically split a variable name at a capital letter in some headings.
    • I like my TITLE statements in open code, not inside a PROC. To me, that makes sense because TITLE statements are global.
    • There should be no conversion messages (character to numeric or numeric to character) in the SAS log. For example use Num = INPUT(Char_Num,12.); instead of Num = 1*Char_Num;. The latter statement forces an automatic character to numeric conversion and places a message in the log.
    • I always use the statement ODS NOPROCTITLE;. This eliminates the default SAS procedure name at the top of the output.
    • Although fewer and fewer people are reading raw text data, I like my @ signs to all line up in my INPUT statement.
    • I like to use the /* and */ comments to define all macro variables. For example:

Notice that I prefer named parameters in my macros, instead of positional parameters.

If this seems like too much work - SAS Studio has an automatic formatting tool that can help standardize your programs. For example, look at the code below:

Really ugly, right? Here is how you can use the automatic formatting tool in SAS Studio.

When you click this icon, the program now looks like this:

That’s pretty much the way I would write it. By the way, if you don't like how Studio formatted your code, enter a control-z to undo it.

For more tips on writing code and how to get started in SAS Studio – check out my book, Learning SAS by Example: A Programmer’s Guide, Second Edition. You can also download a free book excerpt. To also learn more about SAS Press, check out the up-and-coming titles, and receive exclusive discounts make sure to subscribe to the SAS Books newsletter.


About Author

Ron Cody

Private Consultant

Ron Cody, EdD is a retired professor from the Robert Wood Johnson Medical School. He now works as a private consultant and a national instructor for SAS Institute Inc. A SAS user since 1977, Ron's extensive knowledge and innovative style have made him a popular presenter at local, regional, and national SAS conferences. He has authored or co-authored numerous books, as well as countless articles in medical and scientific journals.


  1. I copied this from one of my favorite SAS programmers that always insisted on "neat looking" SAS code. I always put this on top of each of my codes so another programmer can easily learn the "purpose" of the program.
    * SAS code: [file address]\ *;
    * Input(s): [file address]\input_example.xlsx *;
    * Output(s): [file address]\output_example.pdf
    * Objective: Why are we writing this SAS program? *;
    * Date: *;

    • For no real reason, I don't like that style of comment, preferring /* comment */ style.
      I've also seen issues when running in batch on Unix if the * comment ; style contains a single apostrophe.

      • Hi Chris.

        You may get two replies from me because I tried earlier and didn't see it.

        I tend to use both the * and the /* */ type comments. For adding comments in a program, I tend to use the *. When I write macros, I like to use the /* */ comments because they can be used withing a SAS statement (see my example in the blog). Thanks for your comments. If you have other ideas about SAS programming styles, either leave a comment or email me directly.


  2. From SQL programmers I have learned to vertically align the commas. Like:

    * use fixed width font;

    proc sql;
    create table aggregate as
    select region
    , month
    , sum(sales) as sales
    from oursystem
    where country = 'France'
    group by 1, 2;

    And I use it also for some macros aligning the = symbols:

    %means2dset(data = oursystem
    , where = (country = 'France')
    , class = region month
    , var = sales
    , stat = sum
    , out = aggregate);

    Just my 2 cents.


Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top