🚀 go-pugleaf

volpe@bart.crd.ge.com (Christopher R. Volpe) wrote:

>In article <4258ak$cj7@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:

[snip]

>>Maybe you misunderstood me. I am _not_ proposing that gotos are a reasonable
>>alternative to multiple return statements. Both are bad and avoidable.

>Ah... Ok. So you prefer the umpteen-levels-of-if-statement-nesting method?

[snip]

I try to stay out of these religious arguments, but you got to me with
this one.  You are implying that these are the only choices.  My
general schema for a function, based on sound psychological resons,
etc., is that it consists of a series of steps (maximum 7), organized
roughly as follows:

boolean foo (int p, ...)
{
     if (step_1_is_to_be_done)
         do_step_1();
     if (step_2_is_to_be_done)
          do_step_2();
     <etc.>
    return rslt;
}

In otherwords, a single return with only a single level of if-nesting.
The guards around each step can be omitted if a step is unconditional,

and can involve testing parameters, results of previous steps, etc.

In practice, the "so_step_X()" gets replaced by a *short* series of
statements when practical, which can lead to *slightly* deeper
nesting, but not much, and the nesting within a step is logically
distinct from the step guards.  Also, the total function length is
limited to about 50 lines (whatever will fit on a screen), so the
nesting is limited by that consideration.

Obviously I don't guarantee that every line of code I write conforms
to this, but the vast majority does.  I have written hundreds of
thousands of lines of C code without ever feeling the slightest need
for either a goto or an extra return.  Not that I avoid them - they
are simply irrelevant.

I think this is conforming to the spirit, as well as the letter, of
Djikstra's original "Goto Considered Harmful" letter, as well as most
other respectable studies I have seen on good style and good
readability.  I have also found it very successful in producing
debuggable, maintainable code.  Considering a function as a series of
steps leading to a well-defined goal tends to avoid the masses of
mashed-togther lumps of unrelated code thatI encounter so often when
taking on other people's code.
--
Peter Curran                               pcurran@inforamp.net