RPG Coding to a Standard

By Nicholas Delessio

IBM RPG is a programming language unique in its complicated simplicity.

Created in the late 1950s, it has slowly but steadily evolved over the course of decades. Punched cards, paper tape, magnetic tape, blinkenlights, green phosphor terminals (or amber if you prefer), CRTs and LCDs have all run-in with the language. As the needs of businesses changed, so too did the language evolve.

With that pedigree, it’s easy to be misled into thinking of RPG as a dinosaur language, but in fact it’s evolved substantially. Today’s Free Format RPG looks nothing like the column-based programs of the 1980s (which in turn look nothing like the punched card cycle programs of the 1960s) yet the new syntax is much more powerful than it’s ever been. That power comes from its simplicity: from the standpoint of other modern programming languages, free format RPG is an extremely simple, extremely easy to read syntax. A programmer familiar in any other modern language looking at a modern RPG program would, at a glance, be able to determine its general function.

That’s because the latest RPG is a modern language.
This is a very good thing; today’s RPG developer has more flexibility than ever to use modern, easy to read conventions in their code. From a business’s perspective, that means easier maintenance, less time chasing down bugs to keep the lights on.

Unfortunately, nothing exists in a vacuum. RPG didn’t reach its current state overnight; there were many small steps along the path to true free-format code, and with each of these steps coding conventions changed just a little bit. It’s easy, as a shop or a developer, to get lost in the state of the art. What are the current best practices for the language? Does learning them make a real difference in the functionality of the code? Is it worth the effort to change from what’s already known and tried? Is simply being free format enough?

While there’s no single answer for everyone, ARCAD has made the effort to aid the modern RPG shop by implementing best practices in CodeChecker.
ARCAD CodeChecker was already a powerful linting tool. It did, and still does, allow shops to define broad metrics, rules and rule sets that can check over just one program, or an entire code base, to make sure that code is up to a business’s specifications. Code not up to those specs can trigger anything from a polite warning to a hard stop error, based on the individual rule and the preferences of the business.

Powerful capabilities indeed.
Up until now it was on the business to define those rules themselves. It made sense that with such a powerful linting tool at our disposal, which can already traverse and remark on a whole code base, we should also come with a set of rules that aid the developer in conforming to the best practices of today. So that’s just what we set out to do.

We traversed the publications. We worked with some of the leading people in the field, like Jim Buck. We drew from our own experience in-house. What we came up with at the end of this exercise was a broad set of Best Practices that can be used as an interactive “style guide” to steer any developer looking to modernize skills toward the path of writing clean, up-to-date code.

Our rules consider the length of variable names (not constrained to 8 character puzzle boxes anymore). We consider the proper declaration of parameters to protect them from unintended changes. We consider the use of qualified names for things like variables and data structures, monitor blocks, variable length fields, and more. ARCAD not only laid these out in an easy to follow document, but implemented all of the rules and rule sets in CodeChecker, so you can stack these rules up to your own code with a few clicks.

No solution is one-size-fits-all, of course. ARCAD recognizes that. That’s why, with the flexibility of CodeChecker, you can selectively apply these rules to your code any way you want. They can (and should) apply only to RPGLE. They may only point to specified libraries, and be disabled or enabled at any severity level you want. We give you the suggestions, but you’re in control.

We also continue to look to expand these rules. RPG is a changing language, after all.
Finally, in being state of the art, CodeChecker is fully compatible with ILE based, Git solutions. This includes compatibility with Git’s new Delta Mode. Our rules aid anything from traditional source members to the bleeding edge in iSeries development. This is a tool that can grow with you.

As business continues to evolve, so does the need for more powerful, simpler code that’s well written and easy to maintain. ARCAD’s CodeChecker helps your business realize those goals by doing the heavy lifting of defining best practices and helping you to identify them in your code. Code written to good, modern practices will be more easily maintained in the future, making your business more agile and your developers more able to quickly make changes and diagnose issues.
We provide you these rules and put this power in your hands.