NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/13203

Internet Message Format | 1992-09-02 | 4.5 KB

Path: sparky!uunet!UB.com!igor!thor!rmartin
From: [e-mail] (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Message-ID: <rmartin.715445973@thor>
Date: 2 Sep 92 14:59:33 GMT
References: <714668024@thor> <[e-mail]> <[e-mail]> <[e-mail]> <rmartin.714931485@thor> <[e-mail]>
Sender: [e-mail]
Lines: 81

[e-mail] (fred j mccall 575-3539) writes:

|In <rmartin.714931485@thor> [e-mail] (Bob Martin) writes:

|>So we have rules.  These rules protect us average types from the guys
|>who think they are "real good drivers".  When some guy blows a stop
|>sign, it doesn't matter to me, one whit, if he is the greatest driver
|>in the world, I will still applaud the cop who pulls him over.

|But the problem is that, all too often, we lose sight of what we
|wanted the rule to do for us and the means BECOMES the goal.  I've
|seen this more times than I care to mention when it comes to 'rules'
|and their 'enforcement'.

And sometimes this is bad, and sometimes this is good.  One of the
reasons for having rules is to limit the number of variables under
consideration.  Programming is hard, any convention that can help us
narrow our focus on the solution could be an advantage.  If the
convention is shown to be usable in all cases, and advantageous in
nearly all, then its adoption as a rule which is never violated gives
us one less thing to think about.

|The real rule on 'goto' ought to be something like, "Presence of a
|goto in code MAY indicate poorly structured and/or overly complex
|code.  Any use of a goto should be carefully examined to determine if
|there are not better alternative structures which will be more easily
|understood and maintained by others.  If, and only if, this is the
|case, use a 'goto'."  Clearly document the purpose and effect of the
|jump at both the 'goto' and 'label'.  Avoid jumps from different
|places to the same label.  Similar rules for various other
|'questionable' or 'abused' constructs.

This is far too weak.  It is tantamount to saying: "use goto when you
feel like it, but be ready to justify it if questioned."  to quote
Jack D. Ripper: "I am going to have to answer for what I have done;
and I think I can."

I think the requirement should read as follows:  "Presence of a goto
indicates a flaw in program structure as defined in the tenets of
Structured Programming.  Goto statements should only be used when
physically necessary to conform to project requirements.  For example,
to increase the throughput of a critical inner loop."

IMHO, there simply isn't any other reason to consider using a goto.

|The argument, "Well, you never NEED to use a goto." is hardly a
|justification for not using them, either.  You can also write
|everything in the world (wrt 'structure') with only a conditional test
|and a jump.  That's hardly a good reason to say that you SHOULD.

You miss the point.  Structured programming is the construction of
algorithms based on 3 control structures {sequence, selection and
repetition} concatenated toghether in a composition hierarchy.  This
hierarchy is the "structure" that structured programming talks about.
It is regular, and it is recursively defined.  And any algorithm can
be made to conform to such a structure.

Conforming algorithms are aggregate of code fragements which are
entered at the top and exit at the bottom.  Each such fragment has a
purpose which is independent of all but the fragment immediately
above, and the fragment immediately below it.  Thus, the clients and
suppliers of the fragment are known and limited.  This makes the
fragments easy to understand and easy to maintain.  The dependencies
between the fragments are regular, and limited, so that changes in one
fragment have a minimum effect on the others.

Now, you never need to violate this structure (except when physical
contraints of throughput or space are extremenly critical).  So why
would you violate it?  What justification is there?  Is it ok to
weaken the structure of a code, introduce foreign dependencies between
modules, and make the code harder to maintain, just because you think
you can write it a bit faster if you don't have to think about it's
structure?



--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 [phone]       C++