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