Re: Perform Thru/Go to vs. Perform - Compile Speed

From: Peter Lacey (lacey_at_mb.sympatico.ca)
Date: 05/08/04 

Date: Sat, 08 May 2004 11:08:16 -0500

LX-i wrote:

> Peter Lacey wrote:
>
> > My prototype was a program I wrote some 3000 lines long with eight GOTO's. Six of them
> > were conditions exactly like the one I listed, one was to the top of the loop, and one
> > was to the end-of-job. Your assumptions about the program structure are not necessary.
>
> Were there any Performs in this, other than in-line? I've found that
> "Go to" is great, if there are no performs in the program.

No. It was a file-conversion program for a very complicated file. Lots of IF's for the
various fields and possibilities but no necessity to loop or jump out of line.

> At that
> point, everything is again "obvious" to the maintenance guy. As Richard
> pointed out, though, mixing the two introduces a level of complexity
> that can be avoided by sticking to one or the other. When I was taught
> COBOL, I was taught to structure programs like
>
> Driver.
> Perform Initialization-Stuff
> Perform [each independent step of the process, such as "edit user
> input", "process input", "output results", etc.]
> Perform Termination-Stuff
> Stop Run. (Or, "Go to Common-Stop-Run-Paragraph.")
>

Which I do myself. But in the protoype I refer to, the flow logic was so simple that to put
the detail logic out-of-line would have made the program structure more complicated.

>
> In my actual job, we have a copy procedure (copybook) that handles
> transaction initialization and termination, but the concept is the same.
> I'm not saying that I use the above structure in every one of my
> programs - I've been known to write paragraphs hundreds of lines in
> length. However, I do try to keep things sensibly modular, and "common"
> code common, so if I need to change a "common" routine, I can do it in
> one place and be done. :)
>
> > I would deny that. I have nothing at all against goto-less programming. I've done
> > some. What I object to is people condemning out-of-hand the use of goto's, with
> > religious fervour. Many of the people who do so have never actually tried it out. Plus
> > I object to the atttitude often expressed that programs with goto's MUST be of lower
> > quality. I know that such is not the case. Normally I'm content to let it go but
> > sometimes my irritation gets the better of me, while all the time I know I'm preaching to
> > the converted.
>
> My issue isn't with go-to, per se. As a maintenance programmer by trade
> (although I'm finding myself in some new development here as of late),
> what I normally see is 20-25-year-old code that was written with a mix
> of Go to and Perform. It -is- difficult to desk-check code like that
> (although it is sort of an acquired art), which leaves most programmers
> in our shop reliant on program-wide traces and variable dumps to try to
> figure out what the program is doing.
>
> Perform can be abused to. I've seen something like
>
> Perform These-Three-Lines.
> These-Three-Lines.
> Perform [stuff]
> Perform The-Next-Four-Lines.
> The-Next-Four-Lines.
> Perform [stuff]
> Perform Yet-Another-Three-Lines.
> Yet-Another-Three-Lines.
>
> ...you get the idea. I believe what it really boils down to is that
> Perform comes back (assuming it doesn't "Go to" out of scope), which
> gives you a somewhat good idea of program flow. However, a poorly
> placed Go to can really mess this up. (As an aside, I don't really care
> for Perform Thru - did you know that "Perform A-Para Thru A-Para"
> equates to "Go to A-Para"?) It's an easy mistake to introduce as a
> maintenance programmer.
>

I have never dared (after the first time I tried it, back in the days before we had in-line
PERFORM's) to use a label as the target of BOTH a GOTO and a PERFORM. By now that practice has
become an instinctive thing. Likewise, I ALWAYS use PERFORM A THRU A-X and never have trouble
with it. The people who never use THRU because disaster can happen if there's an extra label
there are quite correct in their practice. But it's only one way to avoid problems.

I appreciate your thoughtful comments.

PL

Relevant Pages

  • Re: Batch file and MFC (Properly Terminating Application)
    ... I never worked with MFC before and I wanted a response ... at it and then make corrections-that is, practice, practice and ... that processes user inputsuch as clicking of Exit Button. ... I give user a few seconds for each input via a while loop where I call ...
    (microsoft.public.vc.mfc)
  • Re: strlen(), K+1: clarification
    ... )> And if Clive used an invariant in a for loop, well, what's wrong with ... a for loop. ... It IS good practice. ... of the terminating value is automatically hoisted out of the loop ...
    (comp.programming)
  • Re: Annoying compiler warning
    ... Having done maintenance work I can tell you that I would take the effort to work back through the changes to find out who put that in and then recommend to the head of development that they get rid of the person responsible and the people who let the code through review. ... If you really are doing it to make the life of a maintenance programmer "more fun" then you should not be working on software at all, not as a job and not as a contributor to open source projects. ...
    (comp.lang.c)
  • Re: strlen(), K+1: clarification
    ... )> And if Clive used an invariant in a for loop, well, what's wrong with ... a for loop. ... It IS good practice. ... of the terminating value is automatically hoisted out of the loop ...
    (comp.programming)
  • Re: Determine if open(2) created or opened (again)
    ... Michael B Allen said: ... In practice the code might work for most cases, ... the exact race condition that makes this functionality impossible. ... goes through the second "if" structure within the while loop ...
    (comp.unix.programmer)
Loading