When transforming PACBASE-generated COBOL code as we do, testing is an important issue. We provide a number of ways of significantly reducing the workload attached to this task, but it remains a concern and has to be taken into account when planning any non-trivial migration project.
So, I can understand the temptation of finding a way to avoid testing altogether; in essence, concentrating on those of the changes to the COBOL source code that will have no impact on how the compiler will produce code.
One can then come up with a minimal story where the source code is improved superficially, by pretty-printing constructs and renaming variables and labels. And that’s where it stops.
Limiting the transformations to this minimal set makes a great sales pitch: testing and its uncertainties are no longer required. And I can imagine that some people may be sensitive to this message.
The problem is, it just does not work. Renaming variables and aligning statements alone does not make the code significantly more maintainable. The developer’s original intention is lost. So is any logic structure driving the behaviour of the program. The code to maintain remains bloated, unstructured and redundant.
The plain truth is that the savings one gets by limiting the transformation, and thereby avoid testing are a fallacy. The resulting system is just not maintainable.
No pain, no gain.