Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site othervax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!philabs!micomvax!othervax!ray
From: ray@othervax.UUCP (Raymond D. Dunn)
Newsgroups: net.lang.c
Subject: Re: "break" statements
Message-ID: <716@othervax.UUCP>
Date: Thu, 31-Oct-85 09:58:49 EST
Article-I.D.: othervax.716
Posted: Thu Oct 31 09:58:49 1985
Date-Received: Sun, 3-Nov-85 06:07:13 EST
References: <195@codas.UUCP> <723@mmintl.UUCP> <258@3comvax.UUCP>
Reply-To: ray@othervax.UUCP (Raymond D. Dunn)
Distribution: net
Organization: Philips Information Systems - St. Laurent  P.Q., Canada
Lines: 23
Summary: 

In article <258@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes:
>....
>	The only thing wrong with goto statements (I never use them) is
>that they make code hard to understand.  There are probably rare cases
>when code is made more clear by the use of goto statements.

Please!  Goto statements do not *intrinsically* make programs hard to
understand,  although like all techniques, if an individual is not familiar
with their use, then to him they may appear "more difficult".

It is my experience that a programmer who does not have his logic clear can
write just as obscure code using a structured language than a "goto'ed"
language.

Specifically, the use of goto's (and especially long jumps) to cut across
normal program logic to handle exception processing, is to my mind, almost a
necessity, and *certainly* simplifies the conditional structure of a
program.  This applies just as strongly to the ability to abort out of
several levels of loops.  Like most programming methods, the careful
choice of label names and use of comments is the key to understandability.


Ray Dunn.   ...philabs!micomvax!othervax!ray