I’ve always said : “I don’t care which coding standard as long as there is one.”
Well, starting this new job I have to change my opinion. They have standards but they just are sh*t.
So to ventilate my frustrations : here ‘s my rant and opinion on which standards are best. It should be a blog but not-having one this forum is the next best option.
Agree or disagree. But I hope you'll enjoy reading.
Standards are scored (by me) on 3 criteria.
- Easy to Read
- Easy to Edit
- Less Error-prone
End-of-Sentence Points : Seriously ? I still can’t believe there are sites who still endorse and enforce this one.
- Did you ever try to put some code within an IF or inline perform, remove an IF or made an inline perform into a section/paragraph?
10% of coding time goes into adding and/or removing points, 30% of first-compile errors are caused by forgot-to-remove points.
- points are hard to see: minus on readability, minus on error-avoidance.
- Having points makes it unnecessary to have END- statements, forgetting a point can create serious logic errors.
If your site is using points and doesn’t enforce END-statements, you’re dealing with morons.
Field prefixes or suffixes : “move RECA-fielda to RECB-fielda “ versus “move fielda-RECA to fielda-RECB”
- Prefixes are “always” perfectly aligned, changing them is easy. One that is different is easy to detect.
- With prefixes the actual fieldnames are also aligned .
Unless you have some other counter-standards like all fieldnames are of the same length and/or receiving fields on MOVEs are right aligned, your eyes and cursor are zig-zagging through the code when using suffixes.
In the compile listing Xref : with suffixes same field, different zones are placed together which can be useful, but I haven’t seen GREAT use.
In short prefixes score a lot better than suffixes.
Placing TOs, PICs, VALUES, COMP-3s on EXACT positions : I think everybody agrees on nicely aligned and indented code, but EXACT ???
What if through indentation some sending fieldnames are too long to put your PIC on pos. 50 or TO on pos. 35?
Do you shift all the TO’s in that group to pos 38 or split that line into two? Trust me : your eyes, fingers and brain will prefer option 1.
IF , AND, OR :
Use brackets!!! That’s obvious.
But on this site for the first time in 25 years they want the ORs in front and the ANDs at the end of the line.
Code:
IF (x = y) AND
( a < b
OR a > c) AND
(t = u)
...
END-IF
WTF? Who can read that? ANDs are equal to IFs, ORs is used in a list of options. Please use this instead:
Code:
IF (x = y)
AND (a < b OR
a > c)
AND (t = u)
...
END-IF
These were my biggest frustrations, but there’s more
The use of the word FILLER, It is not necessary following code is correct:
Code:
03 PIC X(4) VALUE ‘See?’.
I hate having to code listings and layouts, but removing all those words FILLER really clear up the screen. One can actually see the variables and values !
There’s more room for longer values. I really like not coding FILLERs and I don’t see any benefit in CODING theml.
Having a standard that obliges me to do so just annoys me.
Sections and Paragraphs and GOTOs:
Please : NEVER use PERFORM … THROUGH … just don’t.
I don’t want to explain. If you need an explanation, just try to follow the flow of the logic in a program that does (once).
So sections are only needed for GOTOs.
I know not all of you will agree, but I don’t like GOTOs except for one reason : GO TO END-OF-SECTION.
Otherwise one will end up with a lot of indented Ifs, especially in a “check-input section”.
GO TO is a dangerous tool in the hand of beginning programmers.
There is no need for it (except for the one stated above) everything else is (mildly said) as nice do-able with PERFORMs and IFs.
I know of sites where they ban all GOTOs , not so much fun but a 100 times better than sites which allow all kind of GOTOs.
And really use this possibility : Different sections can have the same name for paragraphs.
Code:
V8500-SOME-NAME SECTION.
...
IF REC1-A < WS-B
GO TO END-OF-SECTION
END-IF
...
END-OF-SECTION.
EXIT.
V8600-ANOTHER-ONE SECTION.
...
IF REC2-A < WS-B
GO TO END-OF-SECTION
END-IF
...
END-OF-SECTION
EXIT.
vs
Code:
V8500-SOME-NAME SECTION.
...
IF REC1-A < WS-B
GO TO V8599-END-OF-SECTION
END-IF
...
V8599-END-OF-SECTION.
EXIT.
V8600-ANOTHER-ONE SECTION.
...
IF REC2-A < WS-B
GO TO V8599-END-OF-SECTION
END-IF
...
V8699-END-OF-SECTION
EXIT.
I deliberately coded an error in the second part of code. One that is easily made when copying pieces of code from one section to another.
Trust me this error is fatal; if you are lucky your program will abend or loop. If your unlucky it ends RC0000 but with wrong results.
Endless is the time I wasted looking for an error ending up on that one GOTO where I (or someone else) forgot to change the 5 into a 6. (rolling eyes).
Having a standard that forces me to use the second example, really pisses me off.
In this case readability contradicts less error-prone, but I’ll choose “Less Errors” every time.
88-levels :There are ok but are they really that useful ?
Code:
MOVE 1 TO SW-EOF
IF (SW-EOF=1)
versus
SET EOF TO TRUE
IF EOF
Used as above, I really don’t feel like they help a lot.
I do like them as a group of distinct values belonging together :
This is a lot more useable and maintainable then having to code these AND/OR in several places.
But when you do use single-value 88-levels : Don't create a standard saying you are not allowed to use SET x TO TRUE.
this one isn't exactly about a COBOL standard, but still annoying
"No Comments in the source. the Technical Analyses Document contains all explanations".
Here the TAD is pseudo-code. That’s fine when someone is starting a completely new program but should be thrown away once the program is finished.
Having to maintain 2 sources : the pseudo-code and the cobol-code is double work. Especially when some of the pseudo-code is not maintained before, and therefor can not be trusted.
A T.A. is not pseudocode it is a mapping/translation of Functional Design to fieldnames, records and values of certain codes. Occasionally splitting a Function into different programs/routines.
Some sites have a too detailed “Functional design” and are left with nothing else but pseudo code as a Technical Design = Methodology implemented wrong.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Whilst I would never accuse you of working at such a site , a lot of application outsourcers are too cheap or have employers too unskilled or inexperienced (probably related to my first point) to run up-to-date software. A lot of standards are likely meant for OS/VS COBOL, and haven't been changed, either through inertia or because the shop is still running OS/VS COBOL.
About 25 years ago, I worked for a client where my predecessor had written several programs in APL. The total documentation he provided was a note saying, "If you can't understand this code by reading it, you have no business changing it". Twenty-five years ago, that was merely arrogant; today it's insane. The typical "software engineer" would have been considered somewhere between a coder and a keypunch operator when I started.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
This seems a good start. It is three ways of saying the same thing, but loses nothing in that. Three sides of the same coin, as it were.
Quote:
Standards are scored (by me) on 3 criteria.
- Easy to Read
- Easy to Edit
- Less Error-prone
Placing TOs, PICs, VALUES, COMP-3s on EXACT positions
I use "logical tabbing" in ISPF, and this does not cause a problem (unless the positions don't have "overlap" between DATA and PROCEDURE divisions). In the old days, 3270 Terminal Assist (I preferred terminals with this to ones which were without but had fancy colours) allowing "word hop" and there is no difference in traversing a line whether words are single- or multi-spaced.
If someone was serious about failing this on QA, I'd be ungruntled, however.
IF , AND, OR :
Code:
IF ( x EQUAL TO y )
AND ( ( a LESS THAN b )
OR
( a GREATER THAN c ) )
AND ( t EQUAL TO u )
...
END-IF
I've not seen any standards to prevent my parenthesis style, but certainly OR/AND in front, or OR/AND at the end - never seen them split. It looks nuts.
The use of the word FILLER
I prefer to paste FILLER, but there is no particular reason to, or not.
88-levels :
Code:
01.
05 PIC X.
88 END-OF-TRANSACTION-INPUT VALUE "Y".
88 END-OF-TRANSACTION-INPUT-NOT VALUE "N".
05 PIC X.
88 END-OF-RECYCLE-INPUT VALUE "Y".
88 END-OF-RECYCLE-INPUT-NOT VALUE "N".
Code:
SET
END-OF-TRANSACTION-INPUT-NOT
END-OF-RECYCLE-INPUT-NOT
TO TRUE
The advantage of the FILLER/implied FILLER is that no-one can set the values of the 88s without using SET.
I rarely have comments in the source, but for a different reason. If my code is not self-explanatory, I comment. If it is self-explanatory, why comment? Lots of comments in a program, they never get maintained.
Definitely, you can't sensibly have a parallel document which accurately reflects the program. That is plain nuts with cream on top. The point of the additional documents is to describe what should be happening, so that there is a reference point between the business requirement (which can be tracked all the way back up the specification/design chains) and the code itself. You can say what the code should be doing, anything else is simply fatuous.
The only standard I've ever balked at (didn't work at your site GuyC) was "every line of code must be commented". Not because it is silly (client pays, I tell them it is silly, if they still want me to do it OK) but because no-one was doing it. Comments were not maintained, even when copying chunks of code from one program to another. Each paragraph was supposed to start with a description, and a PERFORMED BY and PERFORMS, manually maintained.
The reason was that the senior staff were HP-3000 COBOL people, with system migrating to a Mainframe. HP-3000 have nothing like the compile-listing we get, and they never looked at the back of a program listing (seriously) to find all the work was already done with some of these things.
I wrote two little bits of Rexx. One deleted all comments in a program. Over 50% of the "source" would disappear, making it much easier to read the code.
The other duplicated every line, and put an asterisk in column seven of one of the pair. Job done.
I won the argument, although the HP-3000 guys continued in their habits...
I go by one basic rule. Code your program as if someone else is going to have to read it for an abend at 2am!
Yes, I like 88's so at 2am I don't have to flip back-and-forth for what a value means.
Yes, I like code lined-up since it's easier to read at 2am. Does not have to be exact everywhere.
Yes, I want to see FILLER at 2am so I don't have to play games with code/data meaning.
Yes, I like to see Comments at 2am for paragraphs and certain areas of code. It helps explain the developers intent.
I always find myself going back-and-forth with 88s.
I know the value of the fields, I can see it in the dump or input record.
But what does this "IF 88-conditionthingy" mean ? Which field is this test on ? Is it true or false ? => go lookup the definition of the 88-level.
Somethings are controlable with good naming standards, but overall : not a fan.
Because native English speakers could have troubled times when they work on programs developed by native Spanish speakers as the variable names might be abbreviated
, a lot of application outsourcers are too cheap or have employers too unskilled or inexperienced (probably related to my first point) to run up-to-date software. A lot of standards are likely meant for OS/VS COBOL, and haven't been changed, either through inertia or because the shop .jpg)
