OpenEuphoria

Re: goto: it's conceded

• Posted by ken mortenson <kenneth_john at ya?o?.com> Jun 02, 2008
• 691 views

Derek Parnell wrote:
 
> David Cuny wrote:
> > Well, sometimes you're nested deep, and you need to get out. Implementing it
> > 
> > without GOTO is messy and error prone. With GOTO, it's clear
> > what's happening and it executes as expected.

Sorry to contradict you but your example demostrates perfectly (with some
elaboration) exactly why GOTO result in less clear code.  Thank you for
providing an example that allows me to make this point...
 
> We can now do this (in V4.0) ...
> 
>    while cond1 label "toplevel" do
>       . . .
>       while cond2 do
>        . . .
>          while cond3 label "anotherpoint" do
>            . . .
>             while cond4 do
>               . . .
>               if abc then
>                   exit "toplevel"
>               else
>                   continue "anotherpoint"
>               end if
>             end while
>         end while
>      end while
>    end while

Any person that wrote this probably expects...

while cond4 do

...to be the beginning of a loop.  Does everybody see that?  The fact
is, it's not.  Here's how I would rewrite the code (without labels) to
make it's functionality much clearer.

procedure example()   
  while cond1 do
    ...
    while cond2 do
      ...
      while cond3 do
        ...
        if cond4 then
          ...
        end if
        if abc then return end if
      end while
    end while
  end while
end procedure

Note that 'while cond4 do' has become 'if cond4 then' which make it much
clearer that no iteration is involved (does anybody disagree?)

I have also promoted this code segment to be a procedure of it's own
which further increases the comprehensibity and maintainability of the
code.  I'm not a theorist.  I'm working programmer (not at the moment,
which allows me the luxury of participating in this forum.)

Anyone who says I've reduced performance by adding a procedure will note
the procedure is outside of these loops.  It's inside the loops (mostly)
where performance is the issue.  Taken to an extreme you could say for
performance just write one long block of code (which may actually be true,
but I don't want anything to do with something that ridiculous... and yes,
I've know programmers that code that way.)

Derek, I'm not picking on you.  The fact that you provided the first
example is highly regarded in my book.  It made it possible for me to
show something that I probably would have just asserted without the
example.

If code works, it's probably best to leave it alone.  In cases where I
must make changes, I'm going to remove every GOTO