Date: Tue, 30 Aug 2005 13:42:40 -0400
Reply-To: "Fehd, Ronald J" <rjf2@CDC.GOV>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Fehd, Ronald J" <rjf2@CDC.GOV>
Subject: Re: Best practice: check for blank macro parameters
Content-Type: text/plain; charset="US-ASCII"
> From: m n
> Dear SAS-L,
> For the common practice of checking that required
> macro parameters are not blank, different programmers
> adopt different approaches:
> * %if &VAR= %then <insert code>
> * %if "&VAR"="" %then <insert code>
> * %if &VAR=%str() %then <insert code>
> * using %superq(), %nrstr, %bquote, %nrbquote, etc in
> various ways.
> Etc, etc.
> Is there any consensus among the gurus as to a Best
> Practice in this regard (i.e. a method that is quite
> likely to work regardless of what users may pass into
> the macro)?
consensus?! I doubt it.
Mark gave a pretty good summary
with a pretty good mix of Pareto's 80%-20% rule,
My $0.02 is that you may measure the programmer's amount of
debugging experience by which construct they use.
I spent a memorable two days of my early macro Learning Experience
trying to get SAS to recognize the two-letter abbreviation for Oregon:
%If &State2 eq OR %then %Let StateName = Oregon;
which deconstructs to:
%If &State2 eq /*blank*/
OR /*condition2*/ %then %Let StateName = Oregon;
and my kludge was
%If "&State2" eq "OR" %then %Let StateName = Oregon;
so: best practice: Know Thy Set of Parameter Values
any time you -might- expect users to supply mnemonics
OR and Nebraska==NE::Not Equal
then be defensive.
this includes setting macro parameters to intelligent defaults
i.e. do not leave named parameters blank
Ron Fehd the macro maven CDC Atlanta GA USA RJF2 at cdc dot gov
This quirk was covered in this paper
SUGI 25: 2000 Indianapolis IN
App Dev 38 Writing for Reading SAS Style Sheet
The Writing for Reading SAS (r) Style Sheet:
Tricks, Traps & Tips from SAS-L's Macro Maven
presented at NESUG-2000