Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ptsfa!ihnp4!cuae2!killer!jfh
From: jfh@killer.UUCP (The Beach Bum)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <1182@killer.UUCP>
Date: Thu, 23-Jul-87 15:48:05 EDT
Article-I.D.: killer.1182
Posted: Thu Jul 23 15:48:05 1987
Date-Received: Sat, 25-Jul-87 14:00:43 EDT
References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <3435@oberon.USC.EDU> <3567@oberon.USC.EDU>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 93
Keywords: C, goto, style
Summary: blah blah blah ...

In article <3567@oberon.USC.EDU>, mlinar@poisson.usc.edu (Mitch Mlinar) writes:
> In article <8321@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
> >> There is a nice class of decision trees which can NEVER be implemented smaller
> >> in a structure and and appear MESSIER when in a structure (to me anyway)
> >> versus just a couple labels and GOTOs to "help the structure out"...
> >
> >Try putting it in a table-driven form before you reject goto-less solutions.
> >Usually still more readable, seldom significantly slower if done carefully.
>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Yes, a table-driven form is goto-free, but I am not sure it is *really*
> readable.  (I admit it is probably more readable than the goto solution.)
> 
> The main point I was trying to make (and supported by your statement),
> is that the code is NOT always faster when done right.  Personally, I prefer
> code that is maintainable, even if there is some speed loss.  (To say that
> correct code is ALWAYS faster and/or smaller is a fallacy.)
> 
> -Mitch

I find when writing programs as finite state machines, that the code is
somewhat less readable _but_ almost always infinitely more correct.
Usually some big switch statement and a table of state changes (anyone
who has written a push down automaton knows just how big these tables can
get for a grammar like C or pascal ...) does the trick.  The actual code
is so simple and the tables can be generated almost automatically (unless
you use yacc, in which case it can be generated automatically :-)

That, in this humble programmer's opinion, is the highest form of structure.
A couple dozen lines of code, and an array with a couple thousand entries ...

The points I am trying to make are:

	1). Readablity affects maintainablity.
	2). Structure affects maintainablity.
	3). Design affects maintainablity.

I _always_ document my goto's (about 1 or 2 percent of my statements)
with a `come from' that describes the state and condition of the program
when execution reaches that point in the code.  This does two things:

	1). Improves the readablity.
	2). (generally) Improves the design.

The second is a result of having to think of what conditions you want
flow control to reach the goto.  Consider the following fragment:
(Keep in mind that I would never actually write this piece of code ...)

	OpenFile (FileName, FilePointer, FileBuffer, RecordSize)
	char	*FileName;
	FILE	**FilePointer;
	char	**FileBuffer;
	int	RecordSize;
	{
		*FilePointer = NULL;
		*FileBuffer = NULL;

		if (access (FileName, 0) == -1)
			goto ErrorExit;

		if ((*FilePointer = fopen (FileName, "r")) == NULL)
			goto ErrorExit;

		if ((*FileBuffer = malloc (RecordSize)) == NULL)
			goto ErrorExit;

	/* Maybe some more processing, and jumps to ErrorExit */
		return (1);

	/* ErrorExit - handle all known forms of errors ...
	 * 	You know how you got here? Right?  You know what to do? Right?
	 */

	ErrorExit:
		if (*FilePointer)
			fclose (*FilePointer);

		if (*FileBuffer)
			fclose (*FileBuffer);

		return (0);
	}

Any questions?  This may not be `structured', ala University Pascal style
structured, but I'd rather see this than some nasty collection of deeply
nested if-then-else-if-...'s or 3 or 4 `error handlers' that look just
like the code in ErrorExit with a few minor changes.

- John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993