Paul said:
Yes, I agree. My point was that one could create new entry points through a
liberal scattering of labels, as in my example.
I don't see what you're saying at all. You certainly cannot create new
entry points to a block of code. A block of code can only be entered at
the beginning, and its statements will be run sequentially until it
finishes (whether due to break, continue, return, throw, or simply
reaching the end of the statements in the block).
So out of curiosity, how do you feel about multiple returns in a method?
How about exceptions? These two are probably are responsible for far
more multiple exit points from a block of code than break or continue.
Yes, it cannot be written in Java, because one cannot have forward
references to a label in Java.
That isn't the issue. It's equally not possible to do:
someLabel:
{
...
}
break someLabel;
even though that's not a forward reference. The point is not the
lexical structure, but that break and continue are statements for
exiting a block, and they can only be used from within the block they
are exiting. Yes, your explanation makes them sound more like goto, to
your advantage, but it's also not accurate, and doesn't explain the
behavior and set of legal situations where these statements can be used.
My sole point was that this ability to scatter labels about, if exercised by
a student or someone in a hurry, would quickly devolve into a jumble of
difficult-to-interpret code.
Here's where we will differ. The random strewing about of any control
structure will result in difficult to interpret code. If you can
demonstrate that people using break/continue to solve real problems are
likely to write difficult code, that would be a different matter.
However, labeling an if statement doesn't qualify as a realistic thing
for anyone to do, unless someone is trying to write nonsense code.
If you want to see nonsense code that's hard to follow but uses only
single exit points from a block of code, here you go:
int a = 1, b;
for (b = 40; a < 17; b += a)
{
while (b % a != 3)
{
if (b & 0xA == 2) b--;
else a++;
}
}
To teach people to write readable code, you teach them to think about
what their code is doing, and choose ways of expressing it that make
sense. Absolute technical rules, like "one entry, one exit", only make
code more readable when they match the logic that the programmer is
writing. If the problem domain expresses something with multiple exits,
then I'd encourage a programmer to use a control structure with multiple
exits -- even if that means starting with "while (true)".
I think structured programming purists would argue that it may take longer
to design an algorithm without break/continue, but the resulting code will
be more comprehensible, not less.
You're ignoring what I said. I didn't say that the algorithm without
break/continue would take longer to "design" (to the extent that a
choice between control structures within a method can be called design),
but that the resulting code will be more complex. Introducing temporary
local variables and extra levels of nesting just to avoid a break
statement is not taking the hard road to doing it right; it's spending
more effort to come up with an inferior result.
I'm mostly ignoring the rhetoric about use of break/continue not really
being structured programming. However, for the sake of those who may
assume Paul's terminology is authoritative, I'll point out that it's
not. When discussing structured programming with others, it would be
helpful to point out if you mean something unusual, like excluding the
use of break and continue statements, instead of the usual structured
programming practices of top-down design, etc.
One often sees college coursework in
which the use of break/continue is simply forbidden,
I've never seen this. Have you seen this?
Why would Sun
go out of their way to design and implement a new extension to a
language feature, when they've only included it as a concession to non-
structured programmers?
Why indeed? [...]
That's not an answer. Clearly, if Sun's engineers thought break and
continue are useless statements that are to be discouraged, they could
have at least not elaborated on them with new innovative features.
Sorry, but you can't claim the language designers at Sun as part of a
movement to abolish these control structures.
Also there is the issue of how they are used. They can easily be misused, as
in my example, so one could argue instead that the circumstances of their
use, not their presence in the language, is the real issue.
I would argue that misuse is the issue, except that I don't see frequent
examples of their misuse. Being able to write confusing nonsense code
is not proof that the constructs in your code are misused, either easily
or frequently. You've given something like a random combination of
English words that obeys all the rules of grammar. Writing real code --
or English -- requires both intelligence, and having something to say.
THEN the question of whether the code says it well can be debated.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
{