by Conrad Weisert, October, 1999
COBOL remains a popular programming language, not only for so-called "legacy" systems but also for new applications. We know that there's a huge difference between good and bad COBOL, but just what is "good COBOL"?
Here are eight rules taken from textbooks, course materials, and organizations' in-house standards manuals. Look them over and for each one tell us whether you concur or disagree. Specifically is it:
Some of them are controversial; let's get a constructive debate going.
Results beginning in April.
We posed these proposed standards some time ago. We've gotten a few replies representing both sides of the arguments. We've summarized the "answers" below. So far, the consensus is that all eight of these "standards" are unnecessarily burdensome and even harmful! Does that mean that detailed COBOL programming standards are ill-advised? Not at all; just these particular standards, found in the handbooks of real organizations,
It's not too late to register your opinions, so let us hear from you. We're also looking for more COBOL programming standards, good or bad. Send us the ones you particularly like or particularly hate. -- October, 2003
Return to IDI Home Page
425-SELECT-WAREHOUSEis the 5th procedure called by
42-ALLOCATE-STOCKis the 2nd procedure called by
4-FILL-ORDERis the 4th procedure called by the main program.
This one turned out to be surprisingly controversial. Several readers expressed enthusiastic support for this standard, reporting that their organizations had been following it for years. Others condemned it as an impediment to maintainability. I firmly support the latter opinion; this burdensome standard is indeed harmful and yields no obvious benefit.
Procedures, like any kind of subroutine, should know as little as possible about their environment and about the context in which they're invoked. Restricting such knowledge facilitates not only future re-use but also modifications of this program.
Embedding hierarchical position in the name is even worse, since
the knowledge is scattered elsewhere in the program wherever
the procedure is referred to. Programs often get restructured
in the course of development and maintenance. What if we wanted to
interpose a new procedure between the main program and
Finally, the proposed standard assumes zero fan-in, that is that each procedure is invoked in only one context. Some readers also felt that the prefixes impaired natural code readability.
A good way of coordinating a structure diagram and a long source code listing is to use the compiler-generated identifier listing. If your compiler doesn't produce one, then you can simply arrange the procedures in alphabetic sequence.
Far better, of course, is to organize the COBOL program as separately compiled subprograms that don't have dozens of procedures in the same source code file. (The CALL verb was a late (1968) addition to COBOL, and by the time it was available many COBOL programmers had become accustomed to organizing their programs around one huge DATA DIVISION with parameterless procedures. Many experts attribute most of the difficulty in maintaining COBOL programs to that tradition.)
-- CW, May, 2000, rev. March 2001
Thank goodness, no one defended this silly proposal, which would
force the programmer to put utterly unrelated data close together while
spreading closely related data (e.g.
I have on my shelf a book called "Structured COBOL" (1986) that recommends this awful practice.
-- CW, May, 2000
PART-NUMBER IN INVENTORYis not.
MOVE CORRESPONDINGis not allowed.
The above two standards are obviously related, since complying with standard #3 renders standard #4 irrelevant.
Two readers wrote in support of these standards, but neither cited any benefit from complying with them. Actually, there are several huge benefits from not complying with them.
I would not only not forbid the use of
-- CW March 2001
While this practice makes sense in the context of huge monolithic programs, it breaks down as soon as we take a more modular approach to program structure. What a program module calls a particular piece of data depends upon the point of view of that program module. Abstract or extremely general names are, in fact, appropriate in a subroutine that performs a general, utility function, such as table look-up, display formatting, or data transformation.
-- CW January 2002
This is another well-intended standard that sometimes suffers in over-zealous enforcement.
Of course a user-maintainable table is usually (but not always) preferable to a
one, but isn't any table better than a page and a half of
During a recent code-review walkthrough, someone pointed out that a table would simplify and shorten the program, only to have the programmer explain that the organization's standards prohibited him from using such a technique unless he also implemented a maintenance facility for the users!
CW, June, 2001
READstatement; for any output file only one
|At first this one generated less controversy than the above.
Everyone thought it was a good idea to localize the program's interface
to a file. Some pointed out that the most common structured code1
for processing a sequential input file uses a priming READ
before the loop.
On the output side, several readers pointed out that programs often need to write different records under different conditions.2 To move those records to a common area in order to invoke the unique WRITE operation with a PERFORM may be less understandable and more error prone than just doing the WRITE. Perhaps the prudent solution is to restrict output operations to a single subroutine.
In one organization, this standard led to another one:
-- CW, October, 2003
-- CW, October, 2003
1 -- Common enough that enlightened organizations
package it for reuse as a COPY module.
2 -- This need was especially common among programmers who used record output for printing reports, since heading lines, body lines, and totals lines had different format and data content. The "Report Writer" feature eliminated the need for that clumsy approach.
Return to Technical articles
IDI home page
Last modified August, 2001.