Is it ever important not to use a period behind a macro variable?

[EinarRoed]

As someone who's almost entirely new to the use of macros in SAS, I wonder if there's ever a reason not to put a period at the end of a macro variable. Can I ever cause any problems in the code by using &my_variable. instead of &my_variable? If so, can somone please provide me with some general guildelines on when I must avoid using a period?

Thank you.

[MichelleHomes · Accepted solution]

Hi,

Generally you would only use a period at the end of a macro variable to delimit the macro variable from text. It relates to tokenization - http://support.sas.com/documentation/cdl/en/mcrolref/62978/HTML/default/viewer.htm#p0gdmopu3arzvln1k...

So if you had the statement %let dsn=Y&year&month; due to tokenization SAS knows the the year macro variable ends due to the & special token. If however you had %let dsn=Y&yearmonth; then are you referring to the macro variable, year or the macro variable, yearmonth? In this case a period is needed to delimit the word year from the text month. %let dsn=Y&year.month would then produce Y2012month if the macro variable year has the value 2012.

If you use multiple ampersands next to multiple macro variables with periods unnecessarily you may end up with unexpected results.

This page from the Macro User Guide may also help explain when to use the period - http://support.sas.com/documentation/cdl/en/mcrolref/62978/HTML/default/viewer.htm#n0700fspmubii5n1v...

Cheers,

Michelle

[Astounding]

I've never encountered a case where it hurts to add the period.  And that covers an awful lot of cases.  That doesn't mean that I alway add the period, since it can be mildly distracting to read the code.  But I can't think of a case where it hurts.

Good luck.

[ballardw]

This thread https://communities.sas.com/thread/35661 has an example where at least in some versions of SAS it can cause a problem.

[chang_y_chung_hotmail_com]

ballardw wrote:

> This thread https://communities.sas.com/thread/35661 has an example where at least in some versions of SAS it can cause a problem.

It would surprise me if it was the dot(.) that caused the problem. I see an unbalanced double quotes in the OP's code (of that thread you mention):

%Let monyyyy = %sysfunc(putn(%sysfunc(today()),monyy7.));
 
%Macro chk;
Data _null_;
if not fileexist("C:\Reports\&monyyyy.\&sysdate.") then
  rc=system("mkdir "C:\Reports\&monyyyy.\&sysdate.");  /* <-- */
Run;
%Let fpath = C:\Reports\&monyyyy.\&sysdate.;
libname rep "&fpath.";
%Mend;
 
%Chk;

[art297]

I don't think the post you referred to was a case where the periods hurt but, rather, where there were unbalanced quotes and, in one case, quotes where there shouldn't have been any.

I'm not trying to justify the method shown below, just curious.  Does the following work on your system?:

Options noxwait;

%Let monyyyy = %sysfunc(putn(%sysfunc(today()),monyy7.));

%Macro chk;

Data _null_;

if not fileexist("C:\Reports\&monyyyy.\&sysdate.") then

rc=system("mkdir C:\Reports\&monyyyy.\&sysdate.");

Run;

%Let fpath = C:\Reports\&monyyyy.\&sysdate.;

libname rep "&fpath.";

%Mend;

%Chk

[ballardw]

It created the directory and sub-directories and succesfuly assigned the library.

In the linked thread removing the period worked when the code didn't work  with the period and worked as desired without the period. In my book one counter-example is sufficient to bring a practice into question.

I also try to minimize the number of constructs using the periods and multiple ampersands because it seems like somewhere along the line I'll get caught in a macro quoting / dequoting quagmire.

[art297]

I, like Chang, doubt if the original code (with periods removed) could have run equally successfully.  The point/question isn't whether the periods are necessary, but whether they can ever cause an otherwise correctly written program to fail.

Yes, it only takes one case to make that point, but I have yet (after 38 years using SAS) seen such a case.

[Tom]

In my experience there are very few uses that require placing a period after a macro variable reference.  When I see code with unnecessary periods after macro variable references it makes me think that the coder was unclear about what they were doing.

[Reeza]

Some people do it so it changes colour in the editor, not the best of reasons for sure but a reason.

[chang_y_chung_hotmail_com]

I think the OP's question is a bit biased already. Correctly understood/used, the optional trailing dot does not cause any trouble at all, thus no reason to avoid it intentionally. In some cases, we must not avoid using it!

I would rather regard a macro coder highly if the person uses trailing dots consistently, including the two trailing dots to end an indirect reference like this:

  %let i = 1;
  %let a1 = x;
  %put &&a&i..;
  %*-- on log
  x
  --*;

I would rather suspicious of the coder if he/she insists that three or more consecutive ampersands are absolutely necessary.

[ArtC]

This was one of the topics discussed during the SAS Global Forum presentation on macro lanugage best practices.  Don Henderson and I are in the process of creating a wiki article on the topic.  Please join the conversation at:

http://www.sascommunity.org/wiki/Macro_Programming_Best_Practices:_Styles,_Guidelines_and_Convention...

The consensus of those at the conference was that the dot should only be used when needed..

[chang_y_chung_hotmail_com]

@Art: Thanks for the link to the wiki page. I've read this with much interest and appreciate of it a lot that you and Don put this useful discussion together!

As the title of the wiki page reads, however, this is a matter of style, not of a syntactic correctness. As such, I am just expressing my preference of a more consistent style of using dots all the time to using it only when necessary. Maybe I am more tolerant of the dots, than most 🙂

I also think it is easier to teach a macro novice to start using it all the time (and tell them that the dot can be dropped when there is other suitable thing(s) in the place for the parser to rely on in getting the desired token, i.e., blanks, semicolons, and so on.), since then you don't have to explain why you need to put two dots in your two-word dataset name when the library name is substituted with a macro var reference: like:

    data &myLib..one;

Or in between a filename and a filetype like:

    infile "&myFileName..dat";

[ArtC]

These are good points and you are right, the use of the trailing dot is more about style.  Either way as programmers learn to use the macro language they will ultimately be best served by understanding the tokenization process.  BTW I like your comment on the wiki article, it makes your point very nicely - thank you for the contribution.

[art297]

  I'll add my 2¢ worth to the wiki but, after seeing extremely experienced programmers missing at least one exception, thought I should add a non-programmer's opinion.  I don't know if I am representative of the typical SAS user/non-programmer but, for me, code has always been acceptable if it worked correctly.

Like Astounding, I have never observed a case where ending a macro variable with a period caused SAS to fail.  I was taught years ago by a SAS instructor who I have great respect for to always end macro variables with a period and, while I don't always do what I'm told, I do try to remember to end my macro variables with periods.  I think the SAS learning curve is steep enough, already, without making it even steeper by trying to institute preferences as requirements.

Thus, for non-progammers at least, I don't agree with the majority opinion.