From: Steve Litt <slitt@...>
Date: 2005-12-14T10:20:27+09:00
Subject: Re: Idiom wanted: do-while

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.

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...

>
> > 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.

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.

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.

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.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com