On Mon, Aug 12, 2002 at 08:05:58PM +0100, Nick Murtagh wrote:
> On Mon, 2002-08-12 at 19:56, Kenn Humborg wrote:
> > Well, you should consider 'break' inside a 'select' statement
> > to be part of the syntax, rather than a control flow modifier.
>
> Why? When it comes down to the assembly level, it gets turned
> into some kind of jump instruction. Should I pretend I don't know
> this when I'm programming?
I know that.  And no, you shouldn't.  But see below.
> > A _mandatory_ part of the syntax, at that.
>
> It's not mandatory. You can leave out the break, and the flow
> of control will continue to the next case. Which can be useful
> in certain circumstances.
I know that, too.
However, the discussion was tending towards
"don't use things like goto and break to alter flow of control
in your program".  While not valid 100% of the time, it's a
reasonable rule of thumb.  The idea is that, when looking at
code, it's easier to see how control moves through a
function if your basic control blocks do all the work.  The
specific example of replacing a break in a while loop with
a modified while() expression shows this.  You only have to
look in one place to see when you'll run off the end of the
loop, not hunt through the whole loop.  (Although that particular
example wasn't really that good, since the extra test was
adding on (... || done) and setting done = true in the loop.
Which is much the same as a break really.)
The idea is to surprise the next programmer as little as
possible when he sees the code.
In a similar vein, having a break in every case of a select
block makes the flow much clearer.  Flow goes in, zero or
one case blocks are executed and flows comes out the bottom.
Leaving out break statements breaks this assumption.
My point is that, while there are a few situations where it
makes sense to leave out the breaks, I usually tend to
consider the break at the end of each case more like the
brace at the end of the while block.
In fact, maybe it wouldn't have been a bad idea if the language
was designed such that the continue statement meant fall through
and break wasn't needed:
select (x) {
case 1:
/* do something - doesn't fall through */
case 2:
/* do something - falls through to next case*/
continue;
case 3:
/* do something - doesn't fall through */
default:
/* do something - doesn't fall through */
}
Still, hindsight and all that.  Sigh.
Later,
Kenn
--
Irish Linux Users' Group: ilug@linux.ie
http://www.linux.ie/mailman/listinfo/ilug for (un)subscription information.
List maintainer: listmaster@linux.ie