Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
GO TO's
Rather than sticking something on the end of some random topic, why not discuss, rationally. Then have a hissy-fit later if you don't get your way :-)
Let's say I said that:
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.
You don't get a structured program just by using more flags than a battleship.
Performs generate a lot of code, and I need performance (sic, sorry).
I want to write code that is easy to maintain.
There are reasons to avoid using GO TO, and reasons to use it. The trick is to know what the reasons are.
I maintain programs, and all I get to see is programs that are more difficult to understand beacause they use GOTO/Perform (delete as applicable) badly.
go to code-after-list
code-after-list.
So, anyone want to contribute a reasoned argument for/against one/the other or whatever.
If it is not reasoned, I get to throw the hissy-fit (my thread, my etiquette).
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".
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
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
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.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
GuyC wrote:
Argument 1:
Quote:
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]
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
prino wrote:
Akatsukami wrote:
... 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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Bill O'Boyle wrote:
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".
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
don.leahy wrote:
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?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Akatsukami wrote:
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.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
Quote:
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.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Bill Woodger wrote:
... 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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
prino wrote:
Bill Woodger wrote:
... 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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
dbzTHEdinosauer wrote:
Quote:
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Ronald Burr wrote:
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.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Ronald Burr wrote:
... 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.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
Bill Woodger wrote:
don.leahy wrote:
Congratulations Bill. This is the first GO TO discussion thread in the history of the internet that didn't deteriorate into a holy war.
Well, not yet anyway.
Thanks... is the last a potential you are worried about, or a threat? :-)
No. 11 for your mainframe wars?
You're right about that. I don't know how I missed that one.
If I wanted to start a holy war I would say something like: "GO TOs are for amateurs who don't know how to think logically".
The discussion group comp.lang.cobol is rife with pointless never ending discussions about sections vs paragraphs, OO vs structured, mainframe vs non-mainframe etc. I don't hang out there any more.
Verbs/instructions/statements or whatever the language calls it arent inherently good or bad. Their use on the other hand .....
Programs are coded well or badly, as I think most people would agree.
I have seen and had to maintain some garbage "perform-rich, goto-free " programs and some excellent "branch-fests" [including self modifying elements ] - the use or absence of certain verbs/instructions do not determine structure or spaghetti
While performance now-a-days is less of an issue, when designing a program, than it once was; when it is ..it really is. But it should still possible to write good, maintainable code.
A good programmer should have the skills to know how to design and code an appropriate solution, including well named variables, good comments [MVC ABC,A1 move A1 to ABC ....WOW!- helpful!]
.... must agree with the literals in PROCEDURE DIVISION thing though
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
don.leahy wrote:
Peter Nancollis wrote:
.... must agree with the literals in PROCEDURE DIVISION thing though
So do I, as long as it doesn't degenerate into:
Code:
05 WS-ONE PIC S9(2) COMP VALUE +2.
. . .
ADD WS-ONE to WS-COUNT
Shucks, yes. And the one without a value clause at all (it can't be looping, look, I add one to it!). And make it unsigned usage display.
What I like to do is to make a seperation. If it is something that is just a number, like adding 1 to control a loop, I use a numeric literal. If it is something that is constant, but has a meaning, and just happens to be a number that is known at the time you write the program, I defined it in WS. Then the things I need are in the XREF, without having to ignore countless (if the literal is 1) irrelevant references. I will even define multiple "constants" with the same value, if necessary, but the name I give each will describe what the thing is about.
I have to admit, the moron can turn it into chaos.
Hey, we're slipping off-topic, and I'm helping!
The thing is, we're not really, because it is about good code vs bad, rather than to go, or not to go.
Does an example of bad code, posted in this forum, necessarily indicate a bad programmer? Or a future bad programmer? I'd have loved to have access to the amount of knowledge here as I was starting out. I wouldn't have liked to be told to "get a different career", however. OK, if I then ask the same dumb question five times in different guises, blow me away.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Peter Nancollis wrote:
Verbs/instructions/statements or whatever the language calls it arent inherently good or bad. Their use on the other hand .....
Programs are coded well or badly, as I think most people would agree.
I have seen and had to maintain some garbage "perform-rich, goto-free " programs and some excellent "branch-fests" [including self modifying elements ] - the use or absence of certain verbs/instructions do not determine structure or spaghetti
While performance now-a-days is less of an issue, when designing a program, than it once was; when it is ..it really is. But it should still possible to write good, maintainable code.
A good programmer should have the skills to know how to design and code an appropriate solution, including well named variables, good comments [MVC ABC,A1 move A1 to ABC ....WOW!- helpful!]
.... must agree with the literals in PROCEDURE DIVISION thing though
I agree. It's the logic, stupid, to misquote someone or other. Or misquote an alleged quote, or whatever.
Performance and Comments. Two more subjects for topics...
I have to say, Peter, when I see your "avatar" I always think of the caption, said through gritted teeth, "Tell. Me. Again. Exactly who dropped the object-deck down there?"
