Date: Mon, 16 Dec 2002 09:08:08 -0800
Reply-To: Bill Anderson <wnilesanderson@COX.NET>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Bill Anderson <wnilesanderson@COX.NET>
Subject: Re: recruiting cheesy, sleasy SAS tricks
Content-Type: text/plain; charset="iso-8859-1"
I would like to second Ian's note below.
SAS has a lot of nice features, many of which are not universally present in
computer languages. One of these is the ability to disable a block of code
by placing it in a macro; then we can reenable it by just invoking the
macro.
Like all real computer languages, SAS also has its share of bugs and
inconsistencies, which we have to learn to live with.
As long as we have to live with the bugs, let's take advantage of the
features that make it possible to write more readable code. One of these is
using macros for disabling code. There have been a number of other
features mentioned in this thread, some of which I have already adopted.
IMHO code presented in a session on 'cheesy tricks' should be limited to
that which either makes SAS programs easier to read, easier to write, or
considerably more efficient at run time. Long ago (late 1950's) I learned
to write bad code with the best; writing good code is much harder, and I am
still learning.
Bill Anderson
----- Original Message -----
From: "Ian Whitlock" <WHITLOI1@WESTAT.COM>
Sent: Monday, December 16, 2002 7:25 AM
Subject: Re: recruiting cheesy, sleasy SAS tricks
> Curt,
>
> It is an interesting trick, but whenever the subject of using commenting
for
> a purpose that isn't commenting I have to ask:
>
> Wouldn't it be better to use program design than a comment to
> solve the problem?
>
> One problem, when you lie, is that you have to keep separating the truth
> from the lie. Commenting out code is a lie in that it purports to be a
> comment, which it is not, and it contains what is purports code, which it
is
> not.
>
> Keeping track of Howard's fine line drawn between sleazy and belonging in
> one of Art Carpenter's papers on job security. Here is a comment that
> definitely crosses the line.
>
> %macro q ;
>
> %******************;
> %*: art's comment ;
> %*; data w ;
> %*; run ;
> %*' ;
> %*; data q ;
> %*; run ;
> %******************;
>
> %mend q ;
>
> %q
>
> Is any SAS code executed in this example? What percentage of people will
> guess or give the wrong answer and how long did it take you to analyze
this
> absolutely trivial SAS code? It contains nothing but comments and a
trivial
> data step.
>
> Some people wield comments like a weapon to prevent you from understanding
> their code.
>
> IanWhitlock@westat.com
>
> -----Original Message-----
> From: Curt Seeliger [mailto:seeliger.curt@EPA.GOV]
> Sent: Thursday, December 12, 2002 5:19 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: recruiting cheesy, sleasy SAS tricks
>
>
> "Michael L. Davis" <michael@BASSETTCONSULTING.COM> wrote in message
> > Hello Friends,
> >
> > I'd like to do a Coder's Corner presentation at NESUG next year on the
> > subject of "Cheesy, Sleasy SAS Tricks".
> > ...
>
> How about 'wheezy'? Below is a method which is similar to Richard
> DeVenezia's sample slimeball, but doesn't mind block comments (but does
> get bothered by lines starting with ;;;;). Place %maybe(); data _null_;
> at the start of the code to be conditionally run, and ;;;; at the end of
> that section. I've found this useful for testing large programs in
> sections when running interactively isn't a good option. The macro
> predicate can obviously be changed to meet other needs.
>
> %MACRO maybe(mode);
> /* Causes subsequent code to be ignored until ;;;; is encountered at the
> start of a line if the value of &debugit is TRUE.
>
> ARGUMENTS:
> mode Mode of operation which causes subsequent code to
> not be run.
>
> ASSUMPTIONS:
> The code being skipped does not include CARDS4/;;;; statements.
> This macro is called outside the data/proc step.
> */
> %IF("&&testmode"="&mode") %THEN %DO;
> DATA _NULL_;
> call execute("DATA _null_; CARDS4; RUN;");
> %END;
>
> %MEND maybe;
>
>
> /* Testing modes - you get to choose the names and values
> */
> %LET NOTEST = 0;
> %LET SET_ARG = 1;
> %LET PARSING = 2;
> %LET ENTIRE = 3;
> %LET ON_TUES = 4;
>
> %LET testmode=&parsing;
>
>
> /* Some code always runs */
> DATA foo;
> DO i=1 TO 40; j=2*i; k=i*j; OUTPUT; END;
> RUN;
>
> /* Some code doesn't */
> %maybe(&on_tues); data _null_;
>
> TITLE "testmode=&testmode";
> PROC FREQ DATA=foo; /* Comments not a problem */
> TABLES k;
> RUN;
>
> ;;;;
>
> /* This code always runs */
> * you get the idea;
>
>
> --
> Curt Seeliger, Data Ranger
> CSC, EPA/WED contractor
> 541/754-4638
> seeliger.curt@epa.gov
>
| 
