"break" statements (Really Re computer science)

[zben at umd5.UUCP]

(For those who have just joined us, the topic under discussion is regarding
 the use of "break" and (multiple) "return" statements.)

In article <918 at rlvd.UUCP> asw at rlvd.UUCP (Antony Williams) writes:
>In article <402 at graffiti.UUCP> peter at graffiti.UUCP (Peter da Silva) writes:

>>Generally because it's not practical to prove code correct in large
>>scale applications. 

>I think what you really mean is that it is not YET practical to prove
>large scale applications wholly correct.  

I avoid the use of short-circuit returns, not so much because of the
provability angle, but because it really burns me up to put debugging
output at the end of a procedure, go through all the hassle of compiling
and linking the code, and then not getting any debug output because the
silly procedure returned short.  Just as it impacts the ease of debugging,
this technique also impacts the ease of extending the code.

This is another complaint against the "one-statement" model.  It's really
a drag to put in a { } pair just because you want to add debug printout
(probably temporarily) in a "one-statement" context.  I much prefer the
Modula-2 "statement block" model.

This is also a complaint against languages that require the semicolon be
left off the last statement in a block.  Of course, that's just where you
want to put the debugging output, and as others have pointed out, 99% of
the time you will NOT remember to put that semicolon back in.
-- 
Ben Cranston  ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben  zben at umd2.ARPA