char** to {'':('',)}

David Bolen db3l at fitlinxx.com
Mon Sep 3 20:21:11 EDT 2001


Grant Griffin <not.this at seebelow.org> writes:

> I can't say I use them much, but I _am_ a big fan of the
> "almost-goto" constructs like return, break, and continue.  In
> particular, I like to do early returns to avoid needless nesting.

While I do use them at times, of the various control interruption
constructs, early returns are probably the least preferable for me of
the bunch, mostly because they increase the risk of missing some
needed cleanup - either when initially written or later when
maintained.  They can also complicate the maintenance of code since
there are many exits from a function complicating analysis.

> Coincidentally, I thought I'd seen everything there was to see about
> gotos until just yesterday, when I saw a new form that I had never
> ever seen (or even thought of) before.  It goes to this:
> 
>    bool foo()
>    {
>        bool flag = false;
>        for (;;)
>        {
>            if (x)
>            {
>               flag = true; 
>               break;
>            }
> 
>            do_stuff;
> 
>            if (y)
>            {
>                flag = true;
>                break;
>            }
> 
>            do_more_stuff;
> 
>            break;
>        }
> 
>        return flag;
>    }
> 
> whereas any sensible person would have done:
> 
>    bool foo()
>    {
>        if (x)
>           return true;
> 
>        do_stuff;
> 
>        if (y)
>           return true;
> 
>        do_more_stuff;
> 
>        return false;
>    }
> 
> or maybe even used gotos <wink>.  This construct occurred repeatedly
> throughout the code.  The author considered it to be a "feature".

While using the loop construct instead of more straight-forward gotos
is a little strange, I'm not sure it's worse (nor less "sensible")
than the the multi-return format, which to my mind complicates
maintenance down the road by having multiple exit points without a
major benefit.  I'd rather burn the flag variable and know that there
was a consistent exit path that used that variable.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list