Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!kcl-cs!glasgow!taylor
From: taylor@glasgow.glasgow.UUCP (Jem Taylor)
Newsgroups: net.lang.pascal,net.lang
Subject: Re: a goto without a label?
Message-ID: <662@glasgow.glasgow.UUCP>
Date: Thu, 31-Jul-86 16:10:56 EDT
Article-I.D.: glasgow.662
Posted: Thu Jul 31 16:10:56 1986
Date-Received: Sat, 2-Aug-86 23:30:53 EDT
References: <2943@ism780c.UUCP> <550@cbmvax.cbmvax.cbm.UUCP> <2954@ism780c.UUCP> <2619@umcp-cs.UUCP>
Reply-To: taylor@glasgow.UUCP (Jem Taylor)
Organization: Comp Sci Dept, Glasgow Univ, Scotland
Lines: 64
Xref: mnetor net.lang.pascal:358 net.lang:1146

In article <2619@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes:
>In article <2954@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>>ps.  Note that a C break statement is nothing more than a goto without
>>specifying the label.  Surely you must agree that a goto without a label
>>makes for more difficult understanding than a goto with a label.
>
>A C `break' is a `go out of the innermost enclosing loop or switch',
>and as such requires knowing its context.  The more locality of
>reference in a statement, the easier that statement is to understand
>by itself, and `break' violates this locality.  But so does `end
>while', and in much the same way; yet I have never heard it argued
>that an `end while' `statement' is hard to understand.  (`End while'
>is semantically a control flow bracket but is written as a statement.
>The same is true of `break'.)
>
>In a language with `break' and `continue' statements, the body of
>a loop is not always entirely executed each time the loop test
>succeeds.  If one makes the assumption that it is, and that turns
>out to be false, naturally one will have trouble understanding the
>code.  It seems simpler not to make that assumption.

I have long avoided constructs which cause only part of a compound statement
or loop body to be executed. As has been pointed out before, it's a matter
of personal taste and style if one does not use some features of a language,
but I feel much happier if I can regard compound statements as single entities
when reading through the code at a higher level; each compound being replaced
conceptually by a procedure call.

However - this suggests that use of the 'return' statement to leave a procedure
body part way through is against my rules of style. In practice, it is. The
same rules of conditional-expression formulation that give me blocks without
breaks, give procedures without returns. I find colleagues have less trouble
with the narrowness of (132) column displays, since I indent with tabs, but
with a sideways-scrolling fullscreen editor that is bearable. The thing which
convinces me that coding without breaks/returns is 'better', is that when
re-formatting other peoples' programs into this form, I have found the resulting
code easier to understand, and often been able to see redundant or duplicated
tests and code sections. 

'RETURNs considered harmful' , anyone ?

-Jem.


( I am talking about 'return from procedure', not 'return value from function'.
However, even in functions, if there are multiple returns each return-result 
should be at the end of it's own section, not hidden in the middle. 
If that makes sense )


-- 
--------------------------------------------------------------------------------

JANET:						'  ,  '  ,  '
	taylor@uk.ac.glasgow.cs			 '    ___ ,  '
USENET:						   , / | \  ,
	{ uk }!cs.glasgow.ac.uk!taylor		'    -o|
Royal Mail:					, '   (J=) ' ,
	J.A.Taylor				~~~~~~~~~~~~~~
	Computer Science			<><
	17 Lilybank Gardens				><>	Jemima
	GB-GLASGOW G12 8QQ				  ><>	   Puddleduck

				"who says it doesn't rain on the west coast ?"