🚀 go-pugleaf

Silly contrived example using multiple gotos (to a single exit point):

void manipulate_the_windows(Window *top)
{
  Window *A = NULL, *B = NULL *C = NULL;
 
  if (top == NULL)
     goto exit_function;

  do_something_with_window(top);
  A = get_subwindow(top);
  if (A == NULL)
     goto exit_function;

  do_something_different_with_window(A);
  B = get_subwindow(A);
  if (B == NULL)
     goto exit_function;

  do_something_with_window(B);
  C = get_subwindow(B);
  if (C == NULL)
     goto exit_function;

  /* All windows I'm looking for are good, so do it  */
  do_something_weird_with_four_windows(top,A,B,C);

exit_function:
  /* Do cleanup here */
}

I think the above code is easier to maintain and modify than if it had
multiple returns, or multiple if statements (nested or otherwise).  The
cleanup code would however consists of if statements checking flags set
in the preceding code, or if the situation allows, simply checking for NULL
values.  Of course this requires that such flags or variables be
initialized correctly.

I programmed for many years rarely using a goto, but in a recent project
working with a team of programmers from another company I saw this
construct being used, and adopted it in order to conform to their coding
style.  I was a little uneasy with it at first, but I found that their
source was quite easy to read and modify.  I was going to post to this
newsgroup asking for comments on this style and I saw this thread going on.

The benefits I see over nested if's are:

1. With nested if's the indentation can become quite unreadable.
   Trying to add code is more error prone (IMHO).
2. I like to see an entire line of code without having to scroll and
   even though you can split lines, as you get more indented you may end
   up with very ugly (IMHO) code.

The benefits I see over multiple if's are:

1. The programmer has to constantly remember what to check for, when the
   point at which the error occurred may have happened many statements
   before.  I prefer to note the error when it occurred, print the error
   message if any, and not worry about it again (until cleanup time).
2. The code is slower (not a major concern).
3. The if statements seem to overwhelm the function.  Each function that
   may generate an error has to accounted for in the subsequent if
   statements.

The benefits I see over multiple returns are:

1. The neccessity to duplicate some or all cleanup code, thus making the
   code larger and more error prone.
2. Having a single exit point helps if you have trace or log functions
   which log the entry and exit from a function.  Of course this is
   probably the same as (1).

Most of these benefits really only apply to *large* functions which do
more than 1 thing.  I saw that 1 poster said that functions should only
1 thing.  While I agree with this in principle, eventually in your main
program you have to call these functions which do only 1 thing and do
multiple things.  In some cases it may be more readable (and efficient)
to have a function do multiple *related* things than to split the function
up into multiple functions.  At least that has been my experience with
large, non-trivial programs.

I wonder how much of the anti-goto sentiment is from people who are biased
by the fact that they have seen goto misused to create spaghetti code, or
heard of its evils, and have never used it in this fashion.  To be honest
I only used this method after trying to conform with the coding style of
another programming shop.

Sorry for the long post but I'm interested in any constructive comments in
support of, or against this style (my bias against goto's is/was so strong
that I'm still undecided :)).