🚀 go-pugleaf

In article <42l7s7$2id@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
>volpe@bart.crd.ge.com (Christopher R. Volpe) wrote:
>>In article <4258ak$cj7@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
>>>volpe@bart.crd.ge.com (Christopher R. Volpe) wrote:
>>>>In article <41t0sb$15e@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
>>>[snip]
>>>
>>>I mean the readability problem that Steve McConnell describes in _Code
>>>Complete_: "It's harder to understand a routine if, reading it at the bottom,
>>>you're unaware of the possibility that it returned somewhere above."
>>
>>With all due respect to Mr. McConnell, I don't read code from the bottom up.
>
>Neither do I, and apparently neither does Mr. McConnell. He says "at the
>bottom," not "from the bottom." Code structure should be random access. One
>shouldn't have to read in a particular direction. (Break is the only exception.
>I can't think of a better alternative to break.)

I find it difficult to believe that you can jump into the middle of a routine
and know exactly what's going on without any prior context.

>
>>>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?
>
>No, of course not. Give me an example, and I'll show you how I'd write it. If
>you're worried about nesting too deep, the function already has problems, such
>as being way too complex. Early returns (and gotos) are usually a way to cope
>with unnecessary complexity.

What constitutes complexity can sometimes be a matter of personal opinion and
taste. Just because "longer" functions can be broken down into smaller ones
doesn't mean that it is always helpful to do so. Just my opinion.

>>>We disagree.
>>
>>On what? On the use of gotos only when the alternative is less readable? Or my
>>claim that multiple return statements are more readable than a bunch of 
>>"goto exit_point;" statements?
>
>The last part. There is always a better alternative to using early returns.
>They are never warranted. Gotos are only warranted in (again) _extremely_ rare
>cases. One should use them infrequently enough to feel slightly guilty when the
>occasion arises. Genuflecting to Dijkstra might even be advisable. :-)

Ok, we disagree. I feel that early returns are more readable, and hence more
justifiable, than gotos.

Silly contrived example using multiple returns:

void manipulate_the_windows(Window *top)
{
  Window *A, *B, *C;

  if (top == NULL) {
	return;
  }

  do_something_with_window(top);
  A = get_subwindow(top);
  if (A == NULL) {
	return;
  }

  do_something_different_with_window(A);
  B = get_subwindow(A);
  if (B == NULL) {
	return;
  }

  do_something_with_window(B);
  C = get_subwindow(B);
  if (C == NULL) {
	return;
  }

  /* All windows I'm looking for are good, so do it */
  do_something_weird_with_four_windows(top,A,B,C);
 
  return; /* Omit this or not as a matter of taste */
}

  
--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com