BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
EinarRoed
Pyrite | Level 9

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. Smiley Happy

1 ACCEPTED SOLUTION

Accepted Solutions
MichelleHomes
Meteorite | Level 14

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


//Contact me to learn how Metacoda software can help keep your SAS platform secure - https://www.metacoda.com

View solution in original post

14 REPLIES 14
MichelleHomes
Meteorite | Level 14

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


//Contact me to learn how Metacoda software can help keep your SAS platform secure - https://www.metacoda.com
Astounding
PROC Star

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
Super User

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
Obsidian | Level 7

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
Opal | Level 21

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
Super User

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
Opal | Level 21

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
Super User Tom
Super User

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
Super User

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
Obsidian | Level 7

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
Rhodochrosite | Level 12

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
Obsidian | Level 7

@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
Rhodochrosite | Level 12

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
Opal | Level 21

  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.

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 14 replies
  • 5068 views
  • 6 likes
  • 9 in conversation