How do you refactor COBOL code for better readability and maintainability?

Refactoring COBOL code for improved readability and maintainability involves key strategies. Breaking down large programs into modules organizes the codebase, while meaningful names and comments enhance comprehension. Reducing redundancy by encapsulating repetitive blocks streamlines maintenance. Embracing modern standards, like structured copybooks, brings a contemporary touch. Thorough testing after each iteration ensures functionality. In summary, these measures simplify development and lay the groundwork for seamless enhancements in the dynamic COBOL programming landscape.

Dead code does not make programs slower. Period. Full stop. End of story. And saying the you can use a debugger to remove it makes absolutely no sense, as you will never see it in a debugger. Sheesh...

When a COBOL program is compiled, based on the OPTIMIZE compiler option, dead code is automatically removed from the resulting load module. However, you must look at removing dead code which makes it harder to manage & maintain your code. Lots of programs are cloned/used as a base to create a new program with a slightly different requirement. Using a lean version makes the new program easier to manage. Removing dead code also reduces the impact when field or file lengths change. If you don't have access to code analyzers, just adding a display to the start of a paragraph and running it with a moderately sized sample can identify potentially unused paragraphs.

Why refactor a running code? You invest ressources and produce possibly more problems. Just leave it as it is, and if you must change that code, try to use its original coding style (except goto-s and exotic switches). If you write a new program, it is of course another case. Then there are the old rules of Structured Programming since 1974. no reason to reinvent them.

So correct Gabor. Many goverment and new law updates needed in the good and well running Cobol programs. Then just contact me here and I will help you. I have >30 years Cobol experience. Have a nice weekend from Jan

Extracting common logic into a paragraph that can be PERFORMed from the core part of the program improves maintainability. It now becomes easier to update should a change in logic happen. It makes debugging easier since you can skip the PERFORM (if you are confident that the logic works/is irrelevant to your debugging)

I would disagree with the statement that comments can make code more readable as there is no guarantee that the comments truly reflect the code functionality so functionality must always be determined from the code not the comments (can one always rely on comments being updated when code changes?). I would never debug code by reading the comments. I do agree that it should be mandatory that any code changes are always documented.

Use “structured” periods. Put the period on the next line so it stands out. That simple convention makes it more difficult to have a fall-through. Fall-throughs can be really hard to diagnose. Gather clauses that are qualifiers into an 88. Put all the application’s 88s into a shared copy book. We used a location type and the IF clauses were everywhere, producing inconsistent results. “If location-can-have-hours” makes so much more sense than “if loc-type is “ST” or “SI”….”. Gathering common copybooks will also create some great documentation that a new developer can use to learn about major pivot points in an application structure.

Why do we refactor a code? - For better readability and maintenance. We can improve a COBOL code by several techniques 1. Using meaningful names for Variable, paragraphs and sections. 2. If a condition or a code is having a complex logic, try to break down into smaller and manageable ones. 3. Make sure there are no duplicate blocks of code. 4. Add a brief comment on complex logic. 5. Follow a standard coding format followed in that project. 6. If the requirement is long and complex, then try to make it simpler by dividing the requirements into multiple simpler modules. Through consistent code reviews or if a project has any automation to check for coding standards as per that project, it would be helpful.

Interesting text seems generic. I would probably start refactoring by reviewing the existing data copybooks and check to see if the data is normalized... missing attributes ect. Then model the workflow with a Warnier-Orr diagram which will detail out the existing work flows for each program in the job. Make sure redundant code is encapsulated in their own subroutines or programs so you are only doing a process once. Then you would be in a position to follow the suggested steps above.

If there is a search criteria for a database call, for example , that is especially complex, build a copybook for it. They will force more consistent results and prevent someone from using “>” when they should use “>=“ or leaving out part of the search criteria.

Never expose row or segment copybooks in a subroutine interface. You lose long-term flexibility if you later decide that a structure must change. Encapsulate database read access from other applications by putting an application subroutine in place that moves each and every variable into calling parameters.