Drawbacks of COBOL-Structuring Tools

Some re-engineering tools can transform unstructured spaghetti code into logically equivalent COBOL with no GO TOs or PERFORM THRUs.

Such a tool can begin a rewrite, and automate some of the drudgery, but the results should not be regarded as a finished product. The tool is no more a substitute for a programmer than an anvil is a substitute for a blacksmith.

Removing GO TOs is Not Enough

A restructuring tool may produce formally structured code, but it is not likely to produce well-structured code with a good style. It takes a human mind to recognize the best way to divide the code up into cohesive, well-defined modules, or to give each paragraph an appropriate name.

In order to reproduce the original logic without GO TO, the tool is likely to invent a series of flags and switches to control the flow of execution. Even if these flags and switches are the best way to control the logic, the tool will probably give them arbitrary and cryptic names.

In various other respects the generated code will almost certainly not conform to your local standards and habits.

Preserving Bugs

Spaghetti code is almost always buggy code. The obvious bugs will have already been eliminated by the time you inherit the program. The remaining ones are subtle; they lie concealed in the convoluted logic until a human being flushes them out.

If the restructuring tool does its job properly, it will carefully preserve every bug in the original code. On the other hand, once the tool has formally restructured the program, the bugs may be easier to recognize.

[home]COBOL Home [spaghetti]Spaghetti code