SAS-L archives -- October 2001, week 1 (#32)

Date:	Mon, 1 Oct 2001 13:50:06 -0500
Reply-To:	Paul Thompson <paul@WUBIOS.WUSTL.EDU>
Sender:	"SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:	Paul Thompson <paul@WUBIOS.WUSTL.EDU>
Organization:	Washington University in St. Louis
Subject:	Re: VALUE
Content-Type:	text/html; charset=us-ascii

<html> <head> </head> <body> Dale McLerran wrote: <blockquote type="cite" cite="mid:200110011809.LAA22751@mail9.bigmailbox.com"> <pre wrap="">Paul, I sometimes use a GOTO statement. Consider the situation in which there is a very complex (long) program that requires specification of certain inputs right from the start. If those inputs are not present, then we will terminate the program (with appropriate message to inform the user why the program did not run). Otherwise, we may have hundreds of lines of code which are executed. Now, if the main code block is hundreds of lines long, I don't think that should be buried in an ELSE DO block. A GOTO allows one to branch out of the program without executing the main code block and without burying the main code block in an ELSE DO block. So, I use GOTO (typically when constructing a macro) in the following way: </pre> </blockquote> me, I bury it in an %ELSE %DO block.  I try to work with careful indenting.  I would like SAS to implement labeled %END statements, which would greatly help.   At least with an %DO-%END, you know where you are going.  At least I do, usually. If it gets that confusing, I make the code into a new macro, remove the code to somewhere else and then it is much clearer.  Sounds like you could do the same.  Get rid of those pesky GOTOs, to boot :-> My normal coding technique is to write everything inside macros anyway.  For instance, here is my generic code structure: %macro _overrun(_bs=1,_es=2); %if (&_bs <= 1 & 1 <= &_es) %then %do; 6000 lines of code %end; %if (&_bs <= 2 & 2 <= &_es) %then %do; 6000 lines of code %end; %mend _overrun; %_overrun(_bs=1,_es=1); Now, this probably seems silly.  However, 1) I seldom have to comment out large code blocks. 2) The code is executed in sensible segments 3) Analyses are never broken into 2 or 3 files, rather it is broken into 2 or 3 code segments, which are executed or ignored as needed. I just use the macro code blocks to cut the code up into coherent and self-contained segments, and execute the ones which are needed.  For that reason, I am almost always working with large blocks of code which I am ignoring.   <blockquote type="cite" cite="mid:200110011809.LAA22751@mail9.bigmailbox.com"> <pre wrap=""> %macro xyz(<list of inputs>); %if <check on inputs indicates problem> %then %do; %put Failed to specify ...; %goto endmac; %end; <major code block goes here> %:endmac; %mend xyz; Defensible? I certainly think so. How would you handle this? Dale </pre> <blockquote type="cite"> <pre wrap="">Date: Fri, 28 Sep 2001 15:36:38 -0500 Reply-To: Paul Thompson <a class="moz-txt-link-rfc2396E" href="mailto:paul@WUBIOS.WUSTL.EDU"><paul@WUBIOS.WUSTL.EDU></a> Paul Thompson <a class="moz-txt-link-rfc2396E" href="mailto:paul@WUBIOS.WUSTL.EDU"><paul@WUBIOS.WUSTL.EDU></a> Re: VALUE <a class="moz-txt-link-abbreviated" href="mailto:SAS-L@LISTSERV.UGA.EDU">SAS-L@LISTSERV.UGA.EDU</a> I cannot ever see any reason to use GOTO. Please, can a defender provide an example of when a GOTO does something that cannot be done using some sensible DO construct? </pre> </blockquote> <pre wrap=""> --------------------------------------- Dale McLerran Fred Hutchinson Cancer Research Center mailto: <a class="moz-txt-link-abbreviated" href="mailto:dmclerra@fhcrc.org">dmclerra@fhcrc.org</a> Ph: (206) 667-2926 Fax: (206) 667-5977 --------------------------------------- ------------------------------------------------------------ --== Sent via Deja.com ==-- <a class="moz-txt-link-freetext" href="http://www.deja.com/">http://www.deja.com/</a> </pre> </blockquote> </body> </html>

Back to: Top of message | Previous page | Main SAS-L page

listserv.uga.edu
Enterprise Information Technology Services
The University of Georgia
listhelp@uga.edu