Implications of automated restructuring of COBOL

Abstract

This paper examines whether mechanical transformations of unstructured program code to a structured equivalent can provide any improvement in understandability. We specifically examine, although are not limited to, a COBOL environment. The paper reviews the basic postulates of structured programming as applied to COBOL, and discusses the transformations caused by an automated restructuring tool.Jerry Sitner has asked the basic question of whether mechanical code transformations (performed by either an automated tool or a human following a set of rigorous rules) can improve the readability of COBOL programs. Assuming equivalence (which is not the case), he asks which of the two expressions is more understandable? IF A = B GO TO C . "Unstructured" IF A = B PERFORM C . "Structured"In COBOL, a GO TO is a non-returning transfer of control and a PERFORM is a returning one. Each computer language has at least one and usually both of these constructs. BASIC has GOTO and GOSUB, PL/I (and PASCAL) has the procedure/function and the GOTO, FORTRAN has the DO and GOTO, etc. The question raises two basic issues, 1) is the structured expression equivalent to the unstructured in meaning and 2) how can understandability of program code be improved. To answer these, we need to examine what structured programming is and why it is better, then address the questions of mechanical transformations of code and of names within programs and systems.