Guest_imported
New member
- Jan 1, 1970
- 0
Wanted soft copy or manuals for COBOL Coding standards.
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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
COBOL Coding Standards
- Thread starter Guest_imported
- Start date
- Status
Coding Standards vary depending on where you work.
There is no one coding standard.
There are coding rules for paragraphs, statements, sections, divisions, etc.
There is a COBOL Standards J4 Committee.
Try reading the FAQ for comp.lang.cobol at: If you do not like my post feel free to point out your opinion or my errors.
There is no one coding standard.
There are coding rules for paragraphs, statements, sections, divisions, etc.
There is a COBOL Standards J4 Committee.
Try reading the FAQ for comp.lang.cobol at: If you do not like my post feel free to point out your opinion or my errors.
You will find that different installations will impose different standards at will.
I once worked for a place that didin't allow you to have nested 'if' statements for more than two levels, and of course there was a ban on the use of Go to (a controversial point but I feel they have their place if say only going to the exit point of a section, or are part of a loop - ooh, I sense impending doom in the form of vitriolic counter arguments!!).
So it really is down to where you work.
Of course there is always a common sense factor to this such as writing READABLE code.
Code should be self documenting and have little need for comments thorugh the use of meaningful variable names and section headings etc rather than excessive use of laborious comments to explain logic.
The most annoying thing is when programmer put comments in for the sake of it despite the fact that they add nothing to what can already be seen. For example, writing * here I open the files* right next to a statement that says OPEN file, or * end of section * next to an exit command.
Avoid the above and you will be fine.
:
I once worked for a place that didin't allow you to have nested 'if' statements for more than two levels, and of course there was a ban on the use of Go to (a controversial point but I feel they have their place if say only going to the exit point of a section, or are part of a loop - ooh, I sense impending doom in the form of vitriolic counter arguments!!).
So it really is down to where you work.
Of course there is always a common sense factor to this such as writing READABLE code.
Code should be self documenting and have little need for comments thorugh the use of meaningful variable names and section headings etc rather than excessive use of laborious comments to explain logic.
The most annoying thing is when programmer put comments in for the sake of it despite the fact that they add nothing to what can already be seen. For example, writing * here I open the files* right next to a statement that says OPEN file, or * end of section * next to an exit command.
Avoid the above and you will be fine.
:
Actually, all of you have opened up a can of worms. And have started a provocative discussion. And I love good, hot discussions.
As for comments and flower boxes, I worked for a company until recently whose standards dictated that all divisions have a clear flower box which designated the divisions. Also each paragraph got its own flower box, with '******' over and under each paragraph name.
I found the flower-boxing to be helpful, as I am far-sighted, and there is nothing worse than not being able to distinguish the linkage division from the procedure division (other than seeing "MOVE" rather than "05 DATA PIC X".
Also I can follow the program better if the paragraphs are marked with flower boxes and are well-organized numerically. My project leader at my current job remarked that paragraph numbering methods should be logical and easy to read for those who later on will be doing maintenance on the program.
And I like comments and use them frequently, and I appreciate others who have used them. Some of our generated, reusable procedure division copybooks are amply commented to explain to whoever uses them what they do.
However, make sure the comments are accurate and up to date. There is nothing worse than outdated comments which don't have a whole lot to do with what is currently happening in the code.
As for "GOTO"s: I only use them in two instances.
One is to go to the end of the paragraph as a designated "EXIT" for that paragraph. Sometimes this is needed to skip over some code in case of error or some other branching consideration.
The other is in online CICS programming where you need a CICS RETURN after an error before the program ends. In error conditions, you frequently have to do a GOTO to the error routine, do the CICS RETURN and get out of there.
Other than that, I avoid them like the plague.
Nina Too
As for comments and flower boxes, I worked for a company until recently whose standards dictated that all divisions have a clear flower box which designated the divisions. Also each paragraph got its own flower box, with '******' over and under each paragraph name.
I found the flower-boxing to be helpful, as I am far-sighted, and there is nothing worse than not being able to distinguish the linkage division from the procedure division (other than seeing "MOVE" rather than "05 DATA PIC X"
. Also I can follow the program better if the paragraphs are marked with flower boxes and are well-organized numerically. My project leader at my current job remarked that paragraph numbering methods should be logical and easy to read for those who later on will be doing maintenance on the program.
And I like comments and use them frequently, and I appreciate others who have used them. Some of our generated, reusable procedure division copybooks are amply commented to explain to whoever uses them what they do.
However, make sure the comments are accurate and up to date. There is nothing worse than outdated comments which don't have a whole lot to do with what is currently happening in the code.
As for "GOTO"s: I only use them in two instances.
One is to go to the end of the paragraph as a designated "EXIT" for that paragraph. Sometimes this is needed to skip over some code in case of error or some other branching consideration.
The other is in online CICS programming where you need a CICS RETURN after an error before the program ends. In error conditions, you frequently have to do a GOTO to the error routine, do the CICS RETURN and get out of there.
Other than that, I avoid them like the plague.
Nina Too
I have no quarrel w/flower boxes, I use them myself. I couldn't give you a scholarly discourse on their benefits, except to say the look nice and do hi-lite the pgraph.
As for comments, I don't think they s/b used to hi-lite the obvious (see my prev post for an extreme example). They're helpfiul when a pgraph does more than its title implies. For ex, I'll use 1000-read-x-file, but the pgraph also checks and preps for EOF, performs cntl break logic, counts, etc. This is worty of comment.
Also if the code does not clearly imply its intent, a comment is called for. Ex,
if cust-trans-cnt = 0 and mstr-file-stat = 23
perf 2300-bld-mstr-rec
end-if
May deserve this comment: *===> I new customer bld mstr-rec
Not the best ex in the world, but you get the idea. Sometimes the technical stmt of the COBOL instructions doesn't convey the business intent. We all know what the stmts do, but sometimes we don't know the why.
Jack
As for comments, I don't think they s/b used to hi-lite the obvious (see my prev post for an extreme example). They're helpfiul when a pgraph does more than its title implies. For ex, I'll use 1000-read-x-file, but the pgraph also checks and preps for EOF, performs cntl break logic, counts, etc. This is worty of comment.
Also if the code does not clearly imply its intent, a comment is called for. Ex,
if cust-trans-cnt = 0 and mstr-file-stat = 23
perf 2300-bld-mstr-rec
end-if
May deserve this comment: *===> I new customer bld mstr-rec
Not the best ex in the world, but you get the idea. Sometimes the technical stmt of the COBOL instructions doesn't convey the business intent. We all know what the stmts do, but sometimes we don't know the why.
Jack
I also should have mentioned that the most helpful documentaion gives trhe reader a good overview of how the pgm approaches the problem. It should use pgraph names when discussing functions and provide an insight as to how the pgm is constructed. Also helpful is a list of pgm functions and their pgraph ids, ex:
10xx- processes all accts in the trans file
11xx- processes all invoices in an acct
12xx- processes all trans in an invoice
7xxx- i/o routines
71xx- i/o for mstr-file
72xx- i/o for trans-file
8xxx- housekeeping & init rtns before proc loops are ececuted
90xx- normal exit ruotines
99xx- abnormal exit routines
Jack
10xx- processes all accts in the trans file
11xx- processes all invoices in an acct
12xx- processes all trans in an invoice
7xxx- i/o routines
71xx- i/o for mstr-file
72xx- i/o for trans-file
8xxx- housekeeping & init rtns before proc loops are ececuted
90xx- normal exit ruotines
99xx- abnormal exit routines
Jack
I can see where obvious comments, especially in the middle of a paragraph, can be distracting. Such as when the code says MOVE FIELD-A TO FIELD-B and then right after this line, a comment says something like "****we're moving the contents of field A to field B****." I've seen a couple of these.
But my most recent project had a program where I wrote some code which utilized the VSAM return code of +13, which means "NOT IN FILE" as a determiner to mean that a new record would be written. And my project leader said that I should put in a comment stating that +13 means "Not in file" so that whoever does maintenance later on doesn't have to look this up.
I like your idea of putting a list of which series of numbered paragraphs does what at the beginnning of the program.
Nina Too
But my most recent project had a program where I wrote some code which utilized the VSAM return code of +13, which means "NOT IN FILE" as a determiner to mean that a new record would be written. And my project leader said that I should put in a comment stating that +13 means "Not in file" so that whoever does maintenance later on doesn't have to look this up.
I like your idea of putting a list of which series of numbered paragraphs does what at the beginnning of the program.
Nina Too
StephenJSpiro
Programmer
I think one of the best standards is to have, as comments in the appropriate source unit, a list of
all copybooks in the program
all programs called by this program
all production jobs which use this program
all programs which call this program
all programs which use this copybook.
There are a couple of library systems which provide this information, but if yours doesn't, this should be an ENFORCED firm-wide standard.
Stephen J Spiro
President, Wizard Systems
all copybooks in the program
all programs called by this program
all production jobs which use this program
all programs which call this program
all programs which use this copybook.
There are a couple of library systems which provide this information, but if yours doesn't, this should be an ENFORCED firm-wide standard.
Stephen J Spiro
President, Wizard Systems
- Status
Similar threads