Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site 3comvax.UUCP Path: utzoo!linus!decvax!decwrl!Glacier!oliveb!3comvax!mikes From: mikes@3comvax.UUCP (Mike Shannon) Newsgroups: net.lang.c Subject: Re: break, continue, return, goto Message-ID: <267@3comvax.UUCP> Date: Mon, 4-Nov-85 18:07:22 EST Article-I.D.: 3comvax.267 Posted: Mon Nov 4 18:07:22 1985 Date-Received: Fri, 8-Nov-85 05:05:12 EST References: <771@whuxl.UUCP> Distribution: net Organization: 3Com Corp; Mountain View, CA Lines: 24 In the cited article, Michael Baldwin write > This is in response to those who think that break, continue, and > multiple returns are bad things. As with anything, they can be > abused, but I find continue and multiple returns extremely useful > for dealing with errors, and break for ending complicated search loops. >....... And I think he has really addressed the critical issue. The important thing is that the code we write clearly show our intention. If you *think* about a problem in a certain way, your code should reflect it. This link between syntax and intention makes programs more reliable, easier to read, and cheaper to maintain. If your code looks 'goto'-ey, you probably should attack your programming problem from a different perspective. Think about the problem in a new way. I think that multiple return and break statements are fine to deal with unexpected error conditions. In this context, boolean loop-termination variables might obscure the author's intention. But when the programmer has a complete choice of data structures and program structure, it's another story. All too often, multiple returns and break statements reflect either a lack of exposure to data structures or fuzzy thinking about the problem which needs to be solved. -- Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes