NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/cplus/13541

Text File | 1992-09-11 | 3.7 KB | 75 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
From: [e-mail] (fred j mccall 575-3539)
Subject: Re: GOTO, was: Tiny proposal for na
Message-ID: <[e-mail]>
Organization: Texas Instruments Inc
References: <[e-mail]> <rmartin.715001372@thor> <[e-mail]> <[e-mail]> <rmartin.715526582@thor> <[e-mail]> <rmartin.716168766@thor>
Date: Fri, 11 Sep 1992 18:36:00 GMT
Lines: 64

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

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

>|There are also places where the rules of Structured Programming do not
>|create the most READABLE or MAINTAINABLE code, either.  In these
>|cases, as well, they should be jettisoned.  This is the problem with
>|having a set of 'usual rules'.  Meeting the rules becomes more
>|important to some people than meeting the goals that the rules are
>|supposed to be helping you with.

>Readability is subjective.  I find code without gotos more readable
>than code with gotos.  Others, like you perhaps, find gotos to be more
>readable in certain circumstances.  Life would be boring if we were
>all the same.

If readability is subjective, why is that usually one of the reasons
that Structured Programming Bigots (tm) always raise when lecturing
about why we should all use The One True Style (tm).

>However, maintainability is much less subjective.  Gotos create
>dependencies between blocks which complicate their flow patterns.
>This makes them intriniscally more difficult to maintain.  Gotos also
>tend to be used to merge many different control flows into one.  This
>is also difficult to maintain since, as time wears on, exceptions
>accumulate in the merged flows.

Nonsense.  If you had included some conditionals in there (e.g. "Gotos
CAN create dependencies ...") I might agree with you.  As is, this is
merely pedantic inflexibility.

Case in point.  Suppose you have a function which, during the course
of it's processing, has a dozen possible error points.  If it checks
status and finds an error at any point, the recovery required is the
same.  If it finds an error at any point, it must not continue to try
to process.  Using your method, one winds up with a dozen flags and
code indented halfway across the page.  Trying to string together what
the total algorithm looks like becomes problematic because of all the
indentation breaks, flags, conditional statements strung from here to
there, etc.

Now lets examine the same situation using my method.  If the recovery
can most reasonably be done by the calling function, I would simply
use multiple exit points and exit the function with an error code at
the first check that failed.  If the error recovery needed a lot of
state information from variables in the function, I would use 'goto'
when an error is found and put the error recovery off by itself (and
would still have 2 returns from the single function).

The only way I see to clean up your approach is to create a function
which does nothing but the error recovery and then pass it however
many dozen parameters it needs so it can know enough about the state
of the calling function.  Even then, you still have all that
indentation running all the way across the bloody page.

[I don't know about you, but none of my compilers implement exceptions
yet.]


--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
[e-mail] - I don't speak for others and they don't speak for me.