Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!netcom!teda!ditka!mcdchg!tellab5!balr!clrcom!rmartin
From: rmartin@clear.com (Bob Martin)
Newsgroups: comp.lang.c
Subject: Single exit standard.  Was: Coding Standards.
Message-ID: <1990Nov19.162709.14766@clear.com>
Date: 19 Nov 90 16:27:09 GMT
References: <14369@smoke.brl.mil> <1990Nov10.191840.21113@clear.com> <IMP.90Nov16123956@marvin.Solbourne.COM>
Organization: Clear Communications, Inc.
Lines: 71

In article <IMP.90Nov16123956@marvin.Solbourne.COM> imp@marvin.Solbourne.COM (Warner Losh) writes:
>In article <1990Nov10.191840.21113@clear.com> rmartin@clear.com (Bob Martin) writes:
>: The lack of standard coding practice IS a big problem for software
>: maintenance.
>
>Agreed.  However, a bad coding standard can make life miserable for
>everybody.
>

Yet _NO_ standard is still worse

>: It specifies that functions should have single entrance and single
>: exit points
>
>This is a bogus restriction, at least in terms of a single exit point.
>

Allow me to make a few additions to your piece of code...

>	if (allocate-memory) {
>		do some stuff
>		if (get-more-memory) {
>			do more stuff
>			if (open-file) {
>				do even more stuff
>				if (alloc more memory) {
>					...
>					status = OK;
---					free more memory
>				}
>				else {
---					LogError(1);
>					status = NO_MEM
---					}
---				close file
>			}
>			else {
---				LogError(2);
>				status = NO_FILE
---				}
---			free-more-memory
>		}
>		else {
___			LogError(3);
>			status = NO_MEM
---			}
___		free allocated memory
>	}
>	else {
___		LogError(4);
>		status = NO_MEM
---		}
>
>	return status;
>

Here we see one of the real benefits of the technique.  The free
calls and close calls can be performed at the correct place,
and it is trivial to insure that they are present and correct.
The ErrorLogs pinpoint exactly which place in the code is failing.

Your assertion that simple programs need not go through this is 
valid so far as it goes.  But how many programs start simple and
then grow...   The burden is not very great, the complexity
of the code is reduced, and the code is more robust against
growth. 
-- 
+-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for |
| rmartin@clear.com    |:R::R:C::::M:M:M:M:| my words but me.  I want  |
| uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all   |
+----------------------+:R::R::CCC:M:::::M:| the blame.  So there.     |