[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python or Perl for a Debian maintainance project?

>>>>> "Nano" == Nano Nano <40208.nospam@comcast.net> writes:

    Nano> On Thu, Feb 19, 2004 at 10:42:56AM +0800, Isaac To wrote:
    >> For me, if "goto" is used in a disciplined way, one shouldn't be
    >> afraid to use them, especially if it simplify your code.

    Nano> I developped a technique for application-level programming:

    Nano> LOCK* lock = get_lock (); int ok = (lock != NULL); if (ok) ok =
    Nano> foo (); if (ok) ok = bar (); if (LOCK != NULL) release (lock);
    Nano> return ok;

    Nano> Instead of:

    Nano> LOCK* lock = get_lock (); if (lock == NULL) goto FAIL; if (!foo
    Nano> ()) goto FAIL; if (!bar ()) goto FAIL; return 1; FAIL: if (NULL !=
    Nano> foo) release (lock); return 0;

    Nano> I prefer the former: the gotos are if (ok)'s instead.  I just like
    Nano> the "not jumping" aspect: as the routine grows in complexity (as
    Nano> it shouldn't, but it does), the depth-one, linear flow is easier
    Nano> for me to grok.

Sorry that I have to express my disagreement.  A goto towards the end of a
function, especially when the label name clearly indicates that, is
straight-forward to read.  To somebody who get used to that sort of code,
"goto out" would says directly that "I'm going out of this function, except
that I have something to clean up.  Apart from that, ignore this case."  The
"if (ok)" construct is much more complicated, and the effect depends on the
composite effects of all the if statements.  So the "if something goto
label" construct has a linear complexity, the complexity coming from the
position where you place the label.  The "if (ok) next_statement" has
exponential complexity, the complexity coming from which statement you place
an "if (ok)" and which you don't.  I, for all purpose, would write a goto


Reply to: