On 12/13/05, Steve Litt <slitt / earthlink.net> wrote:
> On Tuesday 13 December 2005 11:09 am, Jacob Fugal wrote:
> > On 12/12/05, Steve Litt <slitt / earthlink.net> wrote:
> > > On Monday 12 December 2005 05:42 pm, James Edward Gray II wrote:
> > > > loop do
> > > >    # ... some action ...
> > > >    break unless ...
> > > > end
> > >
> > > I do this quite a bit, but it's not structured programming and is a
> > > little like a goto.
> >
> > I see no similarity. 'goto' is unstructured because the target point
> > is completely arbitrary; place a label in your code then jump right to
> > it. 'break' is completely structured; it's part of the structure of
> > the enclosing loop and its target is defined by that structure.
>
> Ahh -- I found a reference. See
> http://en.wikipedia.org/wiki/Structured_programming, and note Dijkstra's
> structured programming definition -- every block of code has one entry point
> and one exit point. Break statements clearly violate the "one exit point"
> rule. I was taught the Dijkstra definition at Santa Monica College.

I'll concede that, but refer to James comment (about one break in a
loop do...end being a single exit point). However, I'd lean towards
the looser definition you mention below. Otherwise, having a function
with more than one return in it (e.g. "return false unless
precondition") would not be structured, and I'd much rather be able to
return early then have to wrap the remainder of the function body in
an if statement.

> That same page also lists a definition not demanding a single exit point,
> allowing for break. I saw a lot of that when I left Santa Monica College and
> programmed in the real world. I also saw code that was horribly obfuscated by
> break statements. More on that...

Just because break can be abused doesn't make it wrong.

> > > Break can improve readability on small loops, but on large loops
> > > maintained by multiple people it can become a nightmare.
> >
> > I agree with James; if the loop is long enough or complex enough for
> > these to be a problem, the body of the loop probably needs some
> > serious refactoring.
>
> It absolutely does. Trouble is, in many shops loops start out 8 lines of code,
> and over many, many years, maintenance programmers, many not experienced,
> most not being privy to original design considerations, add features demanded
> by management on ultra-tight schedules. A few years later it's 100 lines of
> code and the break statement is in the middle of it.

Hence the need for continuous refactoring. If that's not taking place,
it management's and/or the developers' fault, not the break
statement's.

> Under those circumstances, the once understandable break statement authored by
> the original programmer can result in unfathomable code, especially if others
> add more break statements.

Again, abuse doesn't mean the item being abused is at fault.

> What I'm saying isn't as important today as it was 15 years ago, when many
> programs were not object oriented. Obviously, something like My_data.to_s can
> easily be refactored just from its name. 15 years ago,
> process_all_valid_incoming_paid_records() could not be.

Point conceded.

> By habit, I always think twice before using break or continue (redo in Ruby).
> If I still want to use it, then I go ahead.

That's a good principle, one I wish many programmers would follow. I,
too, have been bitten by unclear breaks. But I've also been bitten by
unclear conditions in 'if' statements, 'while' statements when 'each'
with a block should have been used, etc. That doesn't mean that 'if'
statements or 'while' statements should be considered harmful. This is
the impression I got about your opinion regarding 'break' when you
lumped it with 'goto'.

Jacob Fugal