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?"
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Nic Clouston wrote:
Quote:
people starting out
Unfortuntely I get the impression that they will not be reading this thread because:
they did not start it
they do not understand it
their code is correct
Not so sure that we've covered anything particularly difficult so that it can't be understood. If there is anything unclear, or obscure, to anyone, feel free to ask.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
OK, this is winding down now. Further comments welcome, but over the weekend I'll try to summarise what has been contributed so far.
Thanks everyone. I enjoyed it.
Now, the next is really not for those with weak hearts. Novices, do not read beyond this point.
OK, I'm sure everyone has one of these, but if you've lost yours...
I apologise, I don't have access to a m/f so I can't test it. Used to work. Optimising off (might not be necessary, I never ran this through an optimiser. Should be OK, but safer off). Possibly CMPR2 but I dont' think so. From memory, but updated for "COBOL II". Sorry if it doesn't work. I've been poring over it, and I think I got everything.
Code:
01 A1-FG PIC X VALUE SPACE.
01 B1-FG PIC X VALUE SPACE.
01 C1-FG PIC X VALUE SPACE.
PERFORM A
IF A1-FG EQUAL TO "Y"
DISPLAY "DO"
GO TO G6
END-IF
.
G1.
PERFORM B
IF B1-FG EQUAL TO "Y"
DISPLAY "DOO"
GO TO G5
END-IF
.
G2.
PERFORM C
IF C1-FG EQUAL TO "Y"
DISPLAY "IN DEEP"
GO TO G4
END-IF
.
G3.
OK, so far not too bad. Some GO TOs, some paragraphs that look suspicious, but straight-forward logic?
Code:
G3.
GO TO C5
.
G4.
GO TO B5
.
G5.
GO TO A5
.
G6.
MOVE +11 TO RETURN-CODE
STOP RUN
.
What the heck is that? As my son would say, quoting the film "Robots".
Code:
A SECTION.
GO TO G1
.
A5.
MOVE "Y" TO A1-FG
.
A9.
EXIT.
B SECTION.
GO TO G2
.
B5.
MOVE "Y" TO B1-FG
.
B9.
EXIT.
C SECTION.
GO TO G3
.
C5.
MOVE "Y" TO C1-FG
.
C9.
EXIT.
Well, goodnes, gracious me. Ponder. Go on, copy-and-paste. Compile. Fingers crossed. Run it.
And no, I don't code my programs like that :-)
But you can get the effect through coding error (which gave me the idea for the program). Kind of like the one Dick mentioned in the original thread.
When I did COBOL, though [and No, its not my code - too structured : o) ] ...In-line performs (and lots lots more that has followed) werent even a twinkle in the compiler's eye
Now if we are collecting topics for venting spleens.... can I add Nested IFs
[at the risk of re-ignition ... more of a maint problem than GOTOs <g,d,r> ]
ttfn
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Quote:
Compile. Fingers crossed. Run it.
Compiles, and works. I'd love to watch it in a debugger.
Peter, I re-raise. You forgot the comments naming the section, listing where it is performed from, listing what it performs, describing what it does. All in a "comment box" which makes sure you don't see a single line of code when you scroll to the section name. And then, of course, a comment for each line of the code. And at least 40% of the comments should be wrong.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
In summary:
There is good code and bad code. Language constructs are not inherently good or bad, they can be used well or poorly.
If you use GO TO, don't do stupid things that are only asking for trouble (like GO TO out of a para/section which is being PERFORMed).
If you avoid using GO TO, don't make the situation as bad going the other way. If it is clearer and more appropriate and avoids more complicated code, why not use GO TO?
Generally, we do avoid/limit use of GO TO.
Thanks to (first come, first served), GuyC, Bill O'Boyle, Akatsukami, don.leahy, prino, dbzTHEdinosauer, Ronald Burr, Peter Nancollis, Nic Clouston.
I'm very pleased when i read your diskussion-blog about using a GOTO.
As i wrote in another topic, my narrow view of a matter is, that experienced programmers, with a minimum of intellect do not need to code a GOTO.
For my own, i do not code a "Branch-Inctruction" in my assembler programms. I use the old IBM Structured Makros wherever i can.
I appreciate this diskussion. I'm allways trying to learn something from such an exchange of experience. Even though i don't know if it's worth for me to do so for the last few years i have to work.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Thank you, UmeySam, I was hoping to attract you to the discussion after your previous comment.
As you have seen from the discussion, mostly experienced people avoid GO TOs and definitely only use them with strict criteria.
People with less experience will not, in my mind, be helped simply by telling them what pieces of language to use, or not use, as this does not in itself, necessarily, of necessity, lead to good, maintainable, code.
As you are one of the more "hard line" who have commented, perhaps you can help out by descring how you deal with the "nesting" issues in the other discussion?