Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need arbitrator: END-IFs and EVALUATE... 7

Status
Not open for further replies.

JFett

Programmer
Dec 7, 2005
10
US
This question is open to everyone, and I would appreciate your responses on these.

1) Can someone tell me what their professional opinion of (and their installation's standards/guidelines on) the use of explicit scope terminators like END-IF/ENDIF? I use them because they're clear and (as their title says) they explicitly terminate the scope of a sequence of code. It makes nested IF's much easier to follow for me. My impression of them is that they MUST'VE been useful to others, since they were added to COBOL in its later variants.

My teammates at work hate them and I'm being run into the ground on it. They'd rather use periods, indentations, and NEXT SENTENCEs as indicators. They're mostly older programmers who are pretty set in their ways/opinions. (To add to their intractability, we don't get along that well.)

2) For another example (and one I'd like your input on as well): I tried to suggest using an EVALUATE statement for a segment of code where they had to consider each digit of a string, and they shot me down, even though it would've reduced the code by a third or more. They preferred using a nested IF structure, but unindented in a "Case-like" format. For example:


IF condition a
statement
ELSE
If condition b
statement
ELSE
IF condition c
statement

(etc)...

On the other hand, here's how EVALUATE would look

EVALUATE variable
WHEN condition a
statement
WHEN condition b
statement
WHEN condition c
statement

(etc)...


To me, it makes for cleaner, more understandable code...but they argue that their way is better. When I suggested the use of EVALUATE (which they weren't familiar with), I got shot down. To me, it seems that everyone else is hell-bent on maintaining THEIR preferences, regardless of what may actually be better or may follow more standard practice elsewhere.

Maybe I'm the crazy one. I'd appreciate you guys letting me know.
 
Ha! that's why they call them Dinosaurs, those old Cobol-scriblers that last went to any decent programming course just after they left high-school, and never ever opened a book on Cobol or whatever other language. That must have been in the late 60's.
Guess their average age is about 65 or so ;-)

Last time I checked, the use of periods in Cobol was to be avoided because it made the language so hard to understand???

JFett, I'm with you, fully.

Please endorse the use of END-IF, EVALUATE, and even (gasp!) the use of lowercase Cobol!!!!!

There's only one (1) kind of good software, the kind that is maintainable . (I mean: Period!)

What do we have against nested if's: it's unreadable, if you have looked away for more that 5 minutes.
What's against the use of periods: they are very hard to see on modern big screens (but the old guys probably still use 14" CRT VT100 terminals, monochrome green character only, and wear glasses that look like a fishbowl), and they (can) terminate en entire section, without obvious reason.

What do we have in favour of end-if: They can (have to) be used inside the evaluate/when/end-evaluate statements, they are very readable, and they do as they say, end and if-statement
What do we have in favour of evaluate: Readability and clearity, similarity to other languages, C, VB, Java, most languages have a 'case' like construction that evaluate offers.

Advise 1: Get your colleagues to have a life, there's more than Cobol these days
Advise 2: If advise 1 doesn't help, go find a decent job, that offer you better future perspectives. If your current colleagues are like this, what will you be like in 20 years?

I could rant on for another half hour or so, but I'll leave that to others :-D

HTH
TonHu
 
I'm 61, have been a COBOL bigot since 1968. End-If's and Evaluate are where it's at I only use periods at the end of a paragraph and after the paragraph name (in the Procedure Division). I never use sections.

The essence of COBOL is that it is readable, even by non-programmers. One program I maintained on my first job had a mutil-case (about 20) nested If Else which I had to submit to the user for vetting. Had Evaluate been available then, it would have been much more readable.

I wrote another program which had a multi-case test requirement. I simulated a case structure with a Perform statement:
Code:
 Perform DUMMY-PARAGRAPH Varying I from 1 by 1 Until I > 1
    At End
        {default code}
    When condition 1
        {condition 1 code}
    etc.
.

BTW, Evaluate is much more than just a case structure. It is in fact a truth-table (remember them?) compiler.
 
JFETT,
Explicit terminators are of great value in delimiting a section of code, but they can be overused. Some programmers feel that every IF MUST have a corresponding END-IF, every PERFORM must have its corresponding END-PERFORM, etc. I've seen instances of a large nested IF structure terminated by a equal number of END-IFs, followed by a period.

Like this:
IF condition-a
statement
ELSE
IF condition-b
statement
ELSE
IF condition-c
statment
ELSE
IF condition-d
statement
ELSE
IF condition-e
statement
ELSE
IF condition-f
statement
END-IF
END-IF
END-IF
END-IF
END-IF
END-IF
.

Now imagine the same chunk of code with 50 IFs, followed by 50 END-IFs, followed by a period. In this case, the 50 END-IFs are overkill, superfluous, since the period by itself terminates all 50 IF conditions.

Most programmers who have been around for a while probably learned to code COBOL using a version of the language that didn't have all the scope delimiters, and they learned to work around that limitation. (Actually, it wasn't seen as a limitation; it's just the way things were.) And once you've done something one way for numerous years (or decades) you're resistant to changing the way you do it simply because it can be done differently. Using END-IFs won't make a program run any faster. In fact, I currently support numerous programs that use scope delimiters extensively, and the programs are over 20,000 lines in length. The programmer could have shaved hundreds or even thousands of lines of code from each program if he hadn't used scope delimiters to terminate a paragraph, as in the above example. The programs are very highly structured in their layouts, but are actually unstructured in their logic. I KNOW that I could have written a BETTER program performing the same functions with at least 1/3 fewer lines.

I personally like the use of EVALUATE, but if I'm coding for efficiency, I'll still use nested "IF"s. Again, some people have gone overboard with EVALUATE, using it to evaluate 2 possible conditions. The EVALUATE command is not as efficient, machine-wise, as multiple IF statements. If I'm evaluating more than a handful of conditions, though, I'll use EVALUATE in most cases.

In case you're wondering, I've been coding COBOL for over 25 years, programming for everything from ancient IBM mainframes (I started on an IBM 360) to superfast Control Data systems, as well as DOS and Windows PCs, and even 8-bit CP/M systems. I've written programs in a dozen different languages.

I've seen some mainframe programmers who are even averse to using a PC to connect to a mainframe to do their work, choosing instead to stick with their old tried-and-true IBM terminal. But there aren't many of those dinosaurs left any more. (Though it sounds like you may be working with some of them.)

Don't let the preferences of others dictate your own personal coding style. Even management needs to realize that the coding standards that they adopted ten years ago may not be the best way of doing things now. But then, you need to remain open to alternative ways of doing things, realizing that "the old ways" aren't necessarily bad. When you stop learning new things (or old things) is when YOU become one of the dinosaurs.

Rich (in Minn.)
 
Oh, now I agree RICHINMINN, END-IFs CAN be overused (and I agree that EVALUATE should be used for multiple conditions). At first, our supervisor grudgingly allowed END-IFs for use with NESTED structures only, which made good sense...even though my habit is to automatically use them, I'll admit there are times when you don't need them. Your example makes sense, too, if you don't have significant ELSE code (or code after the paragraph)...although if those were similar conditions or used the same field(s), I'd've used EVALUATE to replace all those IFs.

However, my teammates picked and picked at the situation until our supervisor finally agreed with them (which is how he felt anyway): No more END-IFs. "They're useless, superfluous, and make things hard to read," they say. And yet, a huge IF structure to evaluate individual characters in a string ISN'T superfluous. Talk about trying to justify things! X-( Unfortunately, they've implemented a standards document which means that we are (read: I am) strictly bound to code in whatever fashions/styles are listed in it. Even if other teams in our installation or the programming world at large have implemented a better style/method. No exceptions.

Anyways, thanks for all the encouragement, everyone.

I'd appreciate more input from others!
 
I'm with most of the others. I switched to "period-less" coding several years ago and haven't looked back. Explicit scope terminators make things MUCH easier to code/follow/test, especially when you get used to them.

I'm not sure about RICHINMINN's statement about EVALUATE efficiency. I've not studied it, but see no reason why it should be more or less efficient than IF logic. You need to watch for maintainability here. An EVALUATE for even 1 or two conditions may make sense if there's any likelihood that conditions will be added over the product's life. It can also lead to catching some bugs or problems that might slip through due to lazy approaches, e.g.
Code:
IF SEX = "M" 
    MOVE "Male"         TO PR-SEX
ELSE
    MOVE "Female"       TO PR-SEX
END-IF
versus:
Code:
EVALUATE SEX
    WHEN "M"
        MOVE "Male"     TO PR-SEX
    WHEN "F"
        MOVE "Female"   TO PR-SEX
    WHEN OTHER
        MOVE "Unknown"  TO PR-SEX
END-EVALUATE
You can certainly be lazy/careless with either form, but it's a little less likely to happen with EVALUATE in my opinion.

One other note: I'd encourage everyone to replace NEXT SENTENCE with CONTINUE wherever it's found. NEXT SENTENCE is just a time-bomb waiting to go off and will ESPECIALLY kill those old dinosaurs who insist on coding "old-style" in a program that has some/all "new-style" coding in it.

Regards.

Glenn
 
Yeah, actually I started learning with just the periods and no scope terminators, went to the scope terminators and never looked back. The worst thing about scope-terminatorless code is debugging. Everything hinges on where that period is. The code even changes meaning.

Anything that makes code cryptic and unclear is a bad thing. So I have to look at a large number of end-ifs sometimes?

As far as RichinMinn goes, if the conditions are mutually exclusive, there's absolutely no reason a block should be coded as it is there. In other languages, the "break" keyword works great for such a situation, which is actually a "GO TO EXIT" in COBOL terms. Actually since there is no break keyword, I have tended, with experience, to actually go for that kind of coding in that case only.
 
One warning has to be added:
whatever style you choose, do no mix "next sentence" with "end-if"'s.

Whenever you maintian -74 style source, leave it as is or remove ALL "next sentences" (at least) in one statement, preferably in one section.

If not, you are a collegue of Stephan King: HORROR
 
Thank you all so much for your encouragement!

It is very frustrating when you know a better way, but you get slammed by people for personal reasons and/or their own personal preference (regardless of what may be better); and they invest a lot of effort in justifying their way and trashing yours. Sometimes it's kind of funny to watch when intricate coding situations pop up and they go through lengths (or make you go through lengths) to do it their way, when the other way would be simpler.

Truusvlugindewind, I agree with you. Personally, I try to avoid the use of NEXT SENTENCE. 3gm mentioned CONTINUE and I like that instead, if I had to use something like that (I'd heard of CONTINUE before, but forgotten about it).

Again, I appreciate everyone's comments and encouragements (a special thanks to TonHu; you made me laugh, and I needed that). I look forward to hearing from more of you on this!
 
You GUYS please don't call us DINOs!!! There are those who are just lazy to reinvent themselves when it comes to programming. It is a hard fact that egos plays the better part of it.

I agree to all of your suggestions about using terminators to an arguments. But that is basically in the eye of the beholder. I always use end-ifs if it is too deeply nested. The best way is to use EVALUATE but not all compilers accept that expression so I'm back to using IFs.

In my case we have several systems that talks to each other like AS400, S390, Tandem and several unixes. Each has it's own version of compiler. Creating a common routines that can be used by all the systems is a daunting task. So I'm back to using IFs statement because some of these compilers does not accept EVALUATE statement. IF statement is the only statement that is common to all of these compilers and yes to make it readable, I have to make sure to use proper indentations. Now that is one heck of a DINO.
 
jmanj, if I understand you correctly, you're saying that you have old and new (or at the very least, "varied") systems in your shop that require an older standard (EVALUATE is from a newer standard). So your situation makes sense for you. :)
But that situation isn't the case where I am.

Also, you mentioned that you agree with the use of explicit-scope terminators...but you also say that it's "basically in the eye of the beholder"...so I'm a little unsure as to your stance. Do you really think that there's no difference one way or the other? Just curious.
 
end-if is a waste of typing.

If you do not like my post feel free to point out your opinion or my errors.
 
Get a grip guys. PC programmers tend to like END-IF. However, a period "." is a scope terminator just like end-if. Personally sometimes the GO TO statement and the NEXT SENTENCE phrase works better. Some programmers may disagree, but there is a special nack involved in the top-down approach to programming. I took Assembly while I took COBOL and purposely used registrs to make brances and returns to make an assembly program look almost exactly like a COBOL program with paragraphs.

I dont think 50 nested IF statements make anything more easy to read.

If you do not like my post feel free to point out your opinion or my errors.
 
In our shop we don't have a policy or standars on how to write our programs. To me the use of IFs and Evaluate produce the same thing. However, Evaluate tends to use more memory. You are right we have varied systems and our only standard of writing programs is to make it easy for others to read it.

While END-IF terminator may not be necessary, we always require it in our programs. As mentioned before, we have varied systems and COBOL is only one of several language we used in our everyday programming. IF statement is almost a universal statement and some of them must be paired with END-IF and some not. We have RPG programmers who does not understand cobol and vice versa. The only thing that I asked from my programmers is to use remarks on what you are trying to do with the logic and pointers to indicate where the flow or directions of your calculations. We can always rest assured that when we are gone, the guy next will understand what we did.

Nowadays we created APIs written in either perl, java, javascript, C, C++, SQR etc as common subroutines and let our cobol programs to call these APIs thus almost eliminates the usage of IFs and EVALUATE in our cobol pgms. Yet ironically enough, we still have to use these statements in those APIs.
 
"PC programmers tend to like END-IF. However, a period "." is a scope terminator just like end-if."

Not really. Big difference being that a period used in coding is often 1) not visible. 2) changes the meaning of an entire block of code depending on location. 3) Are hard to debug.

I've seen people look at code for hours to try to debug something that was caused by code that didn't have the thought meaning because a period was placed in the code either inadvertently or the meaning of the code was not clear.

Really I think this illustrates a great concept and difference in how people think. The people (yes dinosaurs) that come from a time where machine storage and usage is expensive always show themselves in this kind of discussion. The paradigm has changed on them, yet they do not change with it. These days, programmer time is much more expensive than disk storage or CPU cycles. Therefore, easier-understood code is a premium, which makes END-IF and EVALUATE hugely preferable, since the clarity of code increases when they are used (increased comprehension, decreased maintenance time, etc).

IMO, anything without scope-terminators is just decprecated code.
 
jmanj -

I too have programmed on a wide variety of platforms as have many others in this group. I can appreciate the difficulties of writing to one standard to run anywhere and certainly you cannot use EVALUATE or scope terminators if you have compilers that are pre-1985 standard. I've not run into that situation yet as most vendors have long since dropped support for the older versions. I suppose there are some software systems that have not been converted from 1968 or 1974 COBOL to a more recent standard. I suspect a case could be made for doing so if the code is under active maintenance.

As for EVALUATE using more memory, I'd be surprised if that's the case. Perhaps if you use a lot of ALSOs you might hand-tune a series of IF statments to use less memory, but I doubt it's the general case. Do you have a specific example you can cite?

ceh-

"PC programmers tend to like END-IF" ... I think anyone who has any experience with other computer languages likes scope terminators. While the period certainly terminates scope, its use or omission has been the source of lots of problems over the years. It's just too easy to get into trouble, e.g.:
Code:
READ MASTER-FILE
    AT END SET EOF-MASTER-FILE TO TRUE
IF NOT EOF-MASTER-FILE
    PERFORM 2110-UPDATE-MASTER-FILE.

Regards.

Glenn
 
I don't understand how people can use periods in place of END-IFs...

-------------------------
Just call me Captain Awesome.
 
As for EVALUATE using more memory, I'd be surprised if that's the case. Perhaps if you use a lot of ALSOs you might hand-tune a series of IF statments to use less memory, but I doubt it's the general case. Do you have a specific example you can cite?

There's more code effectively generated, and in that sense more memory used. As I understand it, "evaluate" generates a pre-fab jump-table. What is that? It's effectively what I described with the if conditions.

Code:
  IF COND-1
    DO THING
    GO TO EXIT-POINT
  END-IF.
  IF COND-2
    DO THING
    GO TO EXIT-POINT
  END-IF.
  IF COND-3
    DO THING
    GO TO EXIT-POINT
  END-IF.
EXIT-POINT.
  EXIT.

Of course, there's a little more to it behind the scenes than that, but that's the best way to think of how an evaluate works. Of course, if you want more specifics, you can always google on "jump-table" and find all you could ever want on the topic.
 
Glenn9999

I took your test code and tried it both as you wrote it (roughly) and with an EVALUATE. My HP COBOL compiler generated almost exactly the same code for either case. Whether or not EVALUATE generates/uses a jump table or any other construct is a choice that the compiler writer makes. Those guys are pretty smart, so I suspect they produce pretty good code either way and the memory requirement for one construct are likely to be similar to the other.

Glenn
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top