From: Jamis Buck <jamis@37signals.com>
Date: 2005-12-14T10:51:42+09:00
Subject: Re: Idiom wanted: do-while

Ok, I admit I'm coming onto this thread a bit late in the game, so  
someone else might have already suggested this:

   i = 0
   begin
     puts i
     i += 1
   end until i > 10

- Jamis

On Dec 13, 2005, at 6:20 PM, Steve Litt 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.
>
> 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
>