It is OK to have experienced guys use GO TO, but if you let the novices at it they will (ab)use it and cause a mess.

says it all.
In Cobol where a life cycle of a program can easily be 15 years : You don't write code for yourself. You write code for the person that has to maintain the program after you.
So you try to make up standards with the least possibility of "a mess".

Generating "Spaghetti Code" is real easy, if (for example), a given program issues a PERFORM to a routine (which has an exit) and once the routine gains control, a GO TO is issued to another part of the program, completely outside of the PERFORMed routine's scope. GO TO's within a routine, that branch to a paragraph label or the exit itself (IMHO) are perfectly OK.

There seems to be an unconscious assumption that everyone is programming in COBOL. I have not written any COBOL in over fifteen years; however I use PL/I regularly. Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit).

Code without GO TOs is generally more readable, understandable, and maintainable than code with GO TOs. Generally. A few years back, the language support people in my shop installed a new version of the Enterprise PL/I compiler. One of our source modules ceased to be compilable; the default IF nesting level for that version of the compiler was 17...and this particular module had a nested IF levels deep!

To reiterate an oft-quoted witticism, it's impossible to make anything foolproof, because fools are so ingenious. That includes writing maintainable code.

It is OK to have experienced guys use GO TO, but if you let the novices at it they will (ab)use it and cause a mess.

says it all.
In Cobol where a life cycle of a program can easily be 15 years : You don't write code for yourself. You write code for the person that has to maintain the program after you.

Agreed. Although you also do it well because you take pride in doing a good job. Happily, the two things co-incide.

Problem remains in this scheme, in 15 years time, who is writing the same standard of code?

Quote:

So you try to make up standards with the least possibility of "a mess".

Guy, you get the prize as the first person to use the word "standards". (It is a worthless prize, so I've thrown it away on your behalf).

But, in my experience, just "standards" aren't enough. "I was following the standards" I have heard many-a-time for a rubbish program produced by someone left on their own with the local standards manual.

Standards can be bad as well as good. What about the "standard" that every line of code has to be commented (yes, I worked there - and this is the one "site standard" that I rigorously ignored). You "locate" a section name, and you are confronted by an "asterix box" saying, erroneously 95% of the time, which other sections perform that on, and which sections it performs (both of which, of course, you can get 100% accuartely from the compile listing). Two pieces of rexx/xedit solved the situation. First to delete every comment in the procedure division (for program analsysis) and secondly to duplicate each line in the procedure, starting each new line with an "*" (to "demonstrate" to the Team Leader that my comments were 100% accurate, which could not be said about one single other program in the system).

Quote:

Argument 2:
Based on my experience, in well-structured programs , both with and without GO TOs :
Coding errors with GO TOs give runtime errors
Coding errors with Performs give compile errors
I personally prefer compile errors.
"And that's all I have to say about that" Forrest Gump

So, that's one for no GO TOs, if I push you one way or another.[/quote]

... Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit). ...

In fact that is the only time you actually need GOTO in PL/I.

True, that is the only time that it is absolutely needed. OTOH, executing the EXIT statement adds 1000 to the return code. Nesting DO groups to avoid it, combined with "prettyprinting" the code (as important for comprehensibility, IMHO, as actual structured programming), can lead to some rather short lines. Better (and more understandable, I think) to just GO TO the end of the program.

Generating "Spaghetti Code" is real easy, if (for example), a given program issues a PERFORM to a routine (which has an exit) and once the routine gains control, a GO TO is issued to another part of the program, completely outside of the PERFORMed routine's scope. GO TO's within a routine, that branch to a paragraph label or the exit itself (IMHO) are perfectly OK.

Bill

Yes. However, as has been alluded in the dog-end of the other topic, when someone copies the section with a GO TO as a model for another, but doesn't correctly change the previously valid GO TO, then you end up with situation "spaghetti".

I would be quite happy if GO TO was dropped from the language. I don't use it, I don't need it.

OK. There are, now, enough control constructs that this could be done. Also makes you think about how to arrange things so that you don't create the absurd with Perform.

However, we come back to the other side of the same problem. Some one who doesn't take the right level of care (either doesn't know to, or can't be bothered to learn how). Same sort of problem as the out-of-control GO TO - ie, program difficult to maintain/re-use.

Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

There seems to be an unconscious assumption that everyone is programming in COBOL.

Well, sort of had no choice. No forum here for just "programming", or maybe should move to the funny stuff to be inclusive.

Quote:

I have not written any COBOL in over fifteen years; however I use PL/I regularly. Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit).

Code without GO TOs is generally more readable, understandable, and maintainable than code with GO TOs. Generally. A few years back, the language support people in my shop installed a new version of the Enterprise PL/I compiler. One of our source modules ceased to be compilable; the default IF nesting level for that version of the compiler was 17...and this particular module had a nested IF levels deep!

So, one for appropriate use.

Quote:

To reiterate an oft-quoted witticism, it's impossible to make anything foolproof, because fools are so ingenious. That includes writing maintainable code.

I'm more optimistic. Although there is no magic bullet (although there's an idea for some...) I think in aiming to achieve maintainable code you can raise the overall standard of coding in a "shop".

Replace "fool" with "user" and it works really well as well. Except the code bit.

Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

only after I BUFNO'd the crap out of it.

Sorry Guys,

a GO TO over a PERFORM does not enhance performance.

some people can not program logically. Either with PERFORMs or GOTO's,
if the logic is crap, the program is crap.

PERFORM's sort of force you to sorta-generate a modular program,
but 90% of those out there causing machine code to be produced by compilers,
just do not understand the process that they are trying to automate.

I dislike GOTO's,
BUT I HATE LITERALS IN PROCEDURE DIVISION
and i am constantly battling with assholes who want to code in lower-case
and will not put lower-case valued data division entries in copybooks.
(means that I had to go thru all my edit macros and force UPPERCASE
anytime I was manipulating/searching for values) - but that is my problem.

Regardless of the rules, if you can not force compliance...
I spent a couple years (couple of decades ago) complaining about the
lack of professionalism, the inability to design even a module in an
effecient manner, and then I realized,
that if these jerks would/could code better,
I would be out of work.
So I have spent the last 20 or so years, compiling (pun intended) a list
of worst offenders,
and thanking every one of them.

... Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

In PL/I, if the alternative is a very deeply nested IF statement, or a SELECT with a very large number of WHENs, and the test is on a numerical value, an array of labels with GOTO LABEL(I)might speed up things significantly. Never actually tried it.

... Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

In PL/I, if the alternative is a very deeply nested IF statement, or a SELECT with a very large number of WHENs, and the test is on a numerical value, an array of labels with GOTO LABEL(I)might speed up things significantly. Never actually tried it.

That's the sort of thing. IBM even suggest it. A "GO TO DEPENDING ON", of all things, over an EVALUATE sort of construct. If GO TO is bad, GO TO DEPENDING ON is much worse. But there might, at a rare time, be a use for it.

Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

only after I BUFNO'd the crap out of it.

Sorry Guys,

a GO TO over a PERFORM does not enhance performance.

No problem with the hijack (mentioned later, but to get it out of the way before I forget). I welcome it.

I wasn't yet saying that. If you look at Prino's latest and my response, that was what I was thinking, not as to using GO TO over PERFORM.

While we're here though, would it be true (that a GO TO over a PERFORM...)? Kind of depends. A PERFORM generates a bus-load of instructions, not only for the PERFORM itself, but around the paragraph/section (my preference as you know) as well, because, paragraphs and sections can be PERFORMed, GO TOd, dropped-into, THRU'd and anything else I've forgotten at the moment.

Now, if you use an optimising compiler (or the now-built-in one) you end up with a satisfyingly small amount of code generated, becuase the compiler knows exactly how the paragraph/section is being used, and can ditch all the irrelevant stuff.

Quote:

some people can not program logically. Either with PERFORMs or GOTO's,
if the logic is crap, the program is crap.

The real point. I'd add to that people starting out, particularly if they're already happy with other languages. The worst people I found as trainees were those with degrees in computing. They had no idea how to work in a team, no idea about how to think about a program before writing it. You could see what bits they'd written first, and then instead of throwing it away cos it was such rubbish, how they'd tried to patch it up, and patch it up. All the time adhering to the site "standards" and "best programming practice" that they thought they knew, cos they had a degree.

Quote:

PERFORM's sort of force you to sorta-generate a modular program,
but 90% of those out there causing machine code to be produced by compilers,
just do not understand the process that they are trying to automate.

I dislike GOTO's,
BUT I HATE LITERALS IN PROCEDURE DIVISION
and i am constantly battling with assholes who want to code in lower-case
and will not put lower-case valued data division entries in copybooks.
(means that I had to go thru all my edit macros and force UPPERCASE
anytime I was manipulating/searching for values) - but that is my problem.

Yeah, you have a cross-reference listing, and the little... literals aren't there.

What about comments? I hate them. Or, rather, I hate the abundance of them. For code that isn't necessarily obvious, OK. Tell it in English (or whatever local language, obviously) what you are doing. Then the next person along gets a real chance to understand whether the code is correct or not. But all the rubbish saying "set this index to that value"? It never gets changed when the program is cloned, and you end up with comments that only misguide. So I don't read them. If I can, I delete them (but usually I can't, I do tend to add little sarcastic extras at times).

Never put my real name on a program either. 1) I don't have the ego. 2) I hate the idea of someone later butchering my program but having my name there (maybe I do have some ego).

Quote:

Regardless of the rules, if you can not force compliance...

Again, this is the thing. However, for me, you have to give a chance, I think, then many trainees and some with more experience will be able to recognise how to do things better (my experience). Then there are still those who are a total waste of space. Total. Total. Total. But I give everyone a chance or two, then know who not to bother with.

Quote:

I spent a couple years (couple of decades ago) complaining about the
lack of professionalism, the inability to design even a module in an
effecient manner, and then I realized,
that if these jerks would/could code better,
I would be out of work.
So I have spent the last 20 or so years, compiling (pun intended) a list
of worst offenders,
and thanking every one of them.

As a COBOL programmer AND an Assembler Programmer AND a REXX programmer, I have no problem with the inclusion of a well-reasoned GO TO in COBOL (note the accent on well-reasoned).
To me, the inclusion of such a GO TO is no worse than the inclusion of one of the many BRANCH instructions (e.g. B, BC, BR, BCR) in an Assembler program (and I don't think I've EVER seeing an Assembler program with zero Branch instructions). No worse than use of the SIGNAL instruction in REXX, either. As long as its use is CLEAR, and APPROPRIATE, and its inclusion AVOIDS more complicated code, it's OK with me.
The only difference (to me) is that, in COBOL, the generated assembler code for IF...ELSE or EVALUATE or NEXT SENTENCE or CONTINUE constructs contain implicit goto's (branches) rather than explicit GO TO's (also brances).
Unfortunately, I've seen both the USE and the NON-USE of GO TO's carried to the extreme.

As a COBOL programmer AND an Assembler Programmer AND a REXX programmer, I have no problem with the inclusion of a well-reasoned GO TO in COBOL (note the accent on well-reasoned).
To me, the inclusion of such a GO TO is no worse than the inclusion of one of the many BRANCH instructions (e.g. B, BC, BR, BCR) in an Assembler program (and I don't think I've EVER seeing an Assembler program with zero Branch instructions). No worse than use of the SIGNAL instruction in REXX, either. As long as its use is CLEAR, and APPROPRIATE, and its inclusion AVOIDS more complicated code, it's OK with me.
The only difference (to me) is that, in COBOL, the generated assembler code for IF...ELSE or EVALUATE or NEXT SENTENCE or CONTINUE constructs contain implicit goto's (branches) rather than explicit GO TO's (also brances).
Unfortunately, I've seen both the USE and the NON-USE of GO TO's carried to the extreme.

Yes. Even a PERFORM is really a set of branches at either end. For fun, we could do it that way, but we'd make mistakes and the compiler doesn't.

I used to use SCRIPT/VS a lot. It has (had) a goto, but nothing for "perform". But, you could goto a value. So I could build performs. In a the spec for an online system I was doing it could show a dummy screen and then return back to the menu, and show another one.

The thing is, how to get programmers to accept "reasonable" use of either GO TO, modern control structures, or a mix as/if necessary.

I found show-and-tell could work with a surprising number. Others, I could spend hours with and not a single thing would sink in. Try again, same thing. Give up. Management problem then, not mine - except I was on support, of course.

I have to admit to doing some horribly wrong things as a trainee. I remember a loop, cancelled eventually (or canceled as IBM like to call it) but the output was not on hold. I was delivered 1000ft of fan-fold paper with nice headings and one line of data on the first page, and then the rest was just 2-asterisks-per-line ad infinitum. My boss sat me down, and spent some time with me (after he had stopped laughing). I got more from that than the six-week Cobol course I had just completed.

... No worse than use of the SIGNAL instruction in REXX, either. As long as its use is CLEAR, and APPROPRIATE, and its inclusion AVOIDS more complicated code, it's OK with me. ...

The SIGNAL instruction in REXX has one advantage over the GOTO's in COBOL and PL/I, it gives you information as to from where it came, which allows you to very easily embed and extract data from inside your EXEC.