Re: break, continue, goto
Re: break, continue, goto
- Subject: Re: break, continue, goto
- From: James Quick <email@hidden>
- Date: Mon, 4 Aug 2003 17:50:31 -0400
On Monday, August 4, 2003, at 11:06 AM, M. Uli Kusterer wrote:
At 19:18 Uhr +1000 04.08.2003, David Thorp wrote:
In my (limited) programming experience (with such things as basic and
pascal many years ago) I learned that spaghetti code is bad and thus
getting out of loops and conditional statements using things like
continue and break (except for the switch statement) and using goto
at any time, are all examples of bad programming, where one should
carefully choose one's exit conditions and conditional statements
very carefully instead.
As it always is in life, you shouldn't take such rules in programming
to be absolutes. There are numerous occasions where break, continue
and even goto are perfectly good (in C). In C++, it would be another
issue entirely, because there they've added constructs to avoid these
problems. But this is Cocoa-Dev after all...
As other have pointed out explicitly, and Uli has expressed generally,
most particular
statements about what to do, or not do, have exceptions.
I think what is most important to a programmer starting out, is an
understanding of why
they were told "don't do this" to begin with. Armed with that, they
are more likely to
develop a good style.
The reason that goto, break, and continue, were originally vilified
back in the 60s, has to
do more with good style, and with psychology than with their
usefulness. The underlying
problem, which the structure programming movement tried to address in
the 60s and 70s,
was that nonlocal branches made programs more difficult to understand.
They did so
in two fundamental ways. First, the programmer could not assume that
the flow of
execution entered a block of code from only one point, and exited a
block of code
from only one point. This made it impossible to verify that any unit
of code always
did what one expected. Another often cited reason for not using them
was that
what happened at the destination was not evident unless the programmer
stopped
reading the code at that point, and went to the destination to read the
other code.
They combined to make programs more complicated and harder to
understand.
The entire reason for avoiding these statements stemmed from a simple
goal.
- Your code should be as simple to understand as possible.
People reading your code later, including yourself, should be able to
understand it.
The days of numeric if statements, and goto statements which use an
arbitrary
line number are long past, however, it is good practice to avoid
dashing the
common assumptions that we make when reading a piece of code. Since it
is
the general case, we are going to assume that a block of code has a
single
entry and exit, even it we wrote it ourselves. Therefore, it's a good
idea to be
hesitant to use them.
It is unwise, however, to be dogmatic about it and refuse to use them.
Why?
Because, avoiding these statements on blind principle can result in
code which
breaks the intent of the original rule - simplicity.
The fact is, that used judiciously, they can enable you to write code
which is
clearer, simpler, and easier to understand. Clarity and simplity
should be your
guiding principles, both as you learn to program, and to apply
throughout your
programming life.
Bad statements don't kill programs, bad programmers do. :-) sorry.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.