Joined: 14 Jul 2008 Posts: 1248 Location: Richfield, MN, USA
I don't see anything wrong with either way it's coded although the 1st way seems more straightforward and easier to read. I would prefer a 3rd way though -- an EVALUATE statement. Oftentimes, your shop standards dictate your coding conventions.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
In your example, the letters "A" through "D" are consecutive in the EBCDIC collating sequence, so (for example) instead of testing for each letter, you could say NOT < 'A' and NOT > 'D', which would consider A-D as valid letters.
But, there are various other methods to do this, such as IF ALPHABETIC AND NOT = SPACE, which would verify only the upper-case letters of A-Z are acceptable.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Code:
IF DELIVERED-TODAY
OR DELIVERED-THIS-WEEK
OR DELIVERED-THIS-MONTH
OR DELIVERED-THIS-QUARTER
DO THIS-EXACT-SOMETHING
END-IF
Where:
Code:
01 A PIC X.
88 DELIVERED-TODAY VALUE SPACE.
01 B PIC X.
88 DELIVERED-THIS-WEEK VALUE SPACE.
01 C PIC X.
88 DELIVERED-THIS-MONTH VALUE SPACE.
01 D PIC X.
88 DELIVERED-THIS-QUARTER VALUE SPACE.
I don't think EVALUATE helps here, as you'll get four places where DO THIS-EXACT-SOMETHING is referenced.
You example is certainly a way of rewriting your original code, and will operate as you expect.
You'll confuse people looking at/maintain your program, though, because they won't be familiar with that.
This will also give you your expected output (with your code):
Code:
IF SPACES = A OR B OR C OR D
DO SOMETHING
END-IF
However, someone looking at that, to understand what it is doing, will have to look at the definitions of B and C and D, because one or more of those could be an 88.
I don't see how you think it is the same as (1=1), or what use it would be if it was.
People from a non-COBOL background are more likely to write like that, as a way of "protecting" the use of an "=" in an IF. However, since in COBOL an = is never "an assignment operator" there is absolutely no need to do that.
So, meaningful condition-names, meaningful data-names, and write for ease of understanding not for shortness of code, which will confuse. As Terry says, your site standards may have a lot of impact on how you should write it anyway.
Sure we could achieve the same feat using conditional names as you have explained and I myself use them more often than not as you have explained.
Moreover this was just and example where I had used variable names a A, B, C or D (in COBOL coding, we seldom use A, B , C or D as variable names either unless a specific need) and all I wanted to know if it works the way that I have explained without any drawbacks( I concur readability is one, but you know as coders our minds always look for all possible solutions same thing, and then picking the best one of the lot, given the time you have).
I agree the coding standards in an organization dictate how one writes his code. This has nothing to do with coding standards in my organization.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If you consult the section on Relation Conditions in the Language Reference you'll see that all is fine with coding it in that way as far as COBOL is concerned:
Quote:
operand-1
The subject of the relation condition. Can be an identifier, literal, function-identifier, arithmetic expression, or index-name.
The reason it may be seen is due to the fear I mentioned earlier. In some languages "if a = 'a string'" is an assignment statement, usually unintended. "if 'a string' = a" won't compile, so putting any literal first gives some "protection" (but only with a string).
I don't see a benefit of doing it that way in COBOL, as people if people aren't used to that.
and then picking the best one of the lot, given the time you have).
