CoBOL (COmmon Business Oriented Language) programs have been around for years, so many of them are of very poor quality, not only because older programs have had more time to degrade due to rushed or careless maintenance, but also because Cobol is a very verbose language that was developed long before techniques such as structured programming. It also suffers from poor design decisions that encourage very kludgy programming. Although it's possible to write good structured code in Cobol using GoTo statements and other atrocities, it's much easier to write terrible code that's hard to follow and even harder to get and keep working.

Fortunately, the Cobol language itself has evolved over the years to keep up, although still not quite to the level of Pascal or even PL/1. Structured Cobol versions such as Cobol II on the IBM mainframe introduced real structure termination (such as the End-If) and Begin-End type statement groups (in-line Performs) so that periods are no longer as necessary. The case structure (Evaluate) was implemented to replace the Computed GoTo. Further refinements added local nested procedures and standard predefined functions. Some versions of Cobol even support recursion. Pointers were also added to greatly simplify interfacing with subsystems like CICS and IMS and using linked lists. These improvements make it much easier to write good quality, modular, structured programs. As a result, there is no longer any excuse for new Cobol programs to be written with GoTo's, Alter's, Perform Thru's, fall thru's, Next Sentence, Sections, simple Exit statements, or periods on executable statements themselves. In fact, most or all of these are unnecessary even for old Cobol compilers without these enhancements. A very few exceptions might exist when dealing with extremely old Cobol implementations or those supporting preprocessors or other interfaces with subsystems like CICS, IMS, or IDMS, and even most of these have developed similar improvements to keep up with Cobol.

An example of poor design in Cobol itself is the ability of a paragraph or section in the Procedure Division to be used in several ways, by fallthru, GoTo, Perform, Perform Thru, etc. even several ways at once in the same program from different points. This violates a fundamental rule of modularity. In most programming languages, a block of code generally can only be executed in one way and that way is obvious for the use (or lack) of specific interface headers or labels. A subroutine is called, a function is used in an expression, and a label implies a GoTo (yuck). Some languages support some overlap between subroutines and functions but those are still modularly invoked, while GoTo's may never come back and you never know where without following the spaghetti. At least when you look at a piece of code you can tell how it's executed without having to look everywhere else. In Cobol you don't have that assurance; you can't tell how a paragraph is used without looking at the whole program, and a paragraph that appears to be used only one way (and even has so far been used only that way) can be used another way every time the program is maintained. This causes an entire additional layer of maintenance headaches and is totally unacceptible.