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

Internet Message Format | 1992-08-29 | 4.6 KB

Path: sparky!uunet!igor!thor!rmartin
From: [e-mail] (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Message-ID: <rmartin.715001372@thor>
Date: 28 Aug 92 11:29:32 GMT
References: <714668024@thor> <[e-mail]> <rmartin.714863091@thor> <[e-mail]>
Sender: [e-mail]
Lines: 92

[e-mail] (Ramon Pantin) writes:


|It is well known that to rewrite code that uses breaks, continues,
|mid-function returns and gotos (in the most general case) you have to
|either:
|    - Add state variables to the head of loops and additional tests
|      of these variables within the bodies of the loops; or
|    - State variables only tested at the head of the loops and
|      code duplication.

Yes, sometimes "duplication" is necessary.  I'll discuss why this is
less of a problem than it seems further on.

|So you either duplicate code (as you did in the example a couple of
|postings ago) or you have to add additional tests within the loops
|(which I showed in my "structured" version of the original C example).

|So your wins are:
|    - Code duplication, difficult to maintain (in one of your
|      previous posts you din't even seem to agree that code
|      duplication was difficult to maintain!); or
|    - A complexity explosion in your code (number of code paths +
|      tests and sets of state variables).

The wins are, separation of all paths into structured blocks with
single entry and single exit.  This is not a complexity explosion, it
is an enumeration of the complexity that already exists.  The pathways
that you would combine by using breaks and continues, I enumerate by
using if/else and "duplicating code".

Now, dupication of code seems like a problem.  And in the strict
sense, it is.  Clearly, if there is a bug in the code, it must be
fixed in all of its duplicated locations.

Or does it?  In fact, often the bug is related to the particular
condition that is being executed.  When paths are combined, the same
stretch of code can be executed under varying conditions.  A
maintainer may find a bug in a fragment of code and "fix" it, only to
find that his fix introduces another bug when that code is being
executed under different conditions.

However, if the code is "duplicated" into each of the paths which
represent different conditions, then the bug can be fixed insitu.

Clearly this is not a perfect solution, but I contend that a program
structure which separates all paths is easier to maintain than one
which combines paths using break and continue.

As for duplication, if you are forced to duplicate more than "N"
lines, where "N" is relatively small; and if the duplicated segment
forms a cohesive unit which performs a well defined function; then you
should consider writing it as a separate function.

|From my informal counts in this thread it seems that most people are
|perfectly happy with break, continue and mid-function returns.  Some
|group of people avoid gotos as a rule of thumb but wouldn't mind using
|them if required, some of these have not used a goto in the last 10 years.
|A smaller group (only you?) avoid all of these contructs completely.

I can assure you, it is not only me.  There has been a fair amount of
private mail on the subject.  However your observation is correct.  It
does seem that many programmers are quite happy using break and
continue.  Moreover, it seems that a smaller, but significant number
of programmers are content to use goto rather than structure their code.

Perhaps this is a contributing factor to the software crisis in this
country, and to why our bug rate per line of code is 100 to 1000 times
greater than it is in Japan.  I have not seen a study of such a
relationship, and I don't know how closely the Japanese adhere to the
principles of Structured Programming, but it is thought provoking, at
least to me.

|In any case Bob, nobody is suddenly going to have a religious experience
|right here and convert themselves to the other camp, so if you don't see
|more followups on this subject it is not because of that, but because this
|subject has already been beaten to death and at least I've got tired of it.

Please don't speak for everyone.  I will accept that you are not going
to have a religious experience in the near future.  But perhaps, as a
result of these tiring postings, others programmers will reconsider
their positions and try the same experiment that convinced me.





--
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++