This TechTip will continue to discuss the documentation topic, focusing on the tools that an RPG programmer has available and offering a few tips to help define a proper documentation strategy (even if you think you don’t need one).

One of my favorite things about “modern” languages is the self-documenting features that most of them have. For instance, Java has Javadoc, a documentation generator from Oracle Corporation that is designed to automatically produce documentation in HTML format from Java source code. The HTML format is used to add the convenience of being able to hyperlink related documents together. The “doc comments” format used by Javadoc is the de facto industry standard for documenting Java classes. Some Integrated Development Environments (IDEs), such as NetBeans and Eclipse, automatically generate Javadoc HTML code. There are a lot of file editors to assist the developer in producing Javadoc source and using the Javadoc information as internal references for the programmer. This made me wonder if we, RPG programmers, had been forgotten by IBM in this regard.

Documenting for the Lazy…I Mean Busy!...Programmer

As far as I know, IBM doesn’t have a similar tool for RPG. However, some inspired programmer (or just someone like you and me who hates to document code) created a tool called RPGLEDOC. This tool translates the Javadoc concepts into ILE RPG’s particular environment, with its multitude of procedures, modules, service programs, and programs (a lot more than there were in the traditional OPM environment). RPGLEDOC comes in two parts:

• A set of programs to generate the RPGLEDOC documentation, which you can download here
• A set of example programs showing how you might view the contents of the documentation using either CGIDEV2 or PHP, which you can download here

RPGLEDOC comes with a PHP/browser-based doc viewer and has a built-in “error-checking” tool to make sure that the users supply all the necessary tags. It’s also extensible, so you can add your own tags as well. Note that that these are not supported products; the source of the programs is included in the downloadable files, and you are free to modify them as you wish.

To my knowledge, there are two other tools worth mentioning:

• The freeware tool ILEDOCS from RPG Next Gen, which does basically the same thing as RPGLEDOC (but I think is not being updated)
• Docu-Mint, from BDC Software, which is commercial software, kept up to date but with a less friendly interface than RPGLEDOC

If you know other tools, please share them in the comments section below. RPG doesn’t have to be complicated, and programmers shouldn’t have to “wing it” every time they look at a piece of source code for the first time. So do yourself a favor and take a moment to define your documentation strategy, even if you don’t think you need one. Trust me, you do.

Defining Your Documentation Strategy

More important than the amount of documentation you think you need (as discussed in the previous TechTip) or whichever tool you decide to use, is making sure you define an appropriate documentation strategy:

• Define the documentation purpose and scope. Are you going to create purely technical documentation, or do you want to include some functional documentation as well? Do you intend to document the whole application in one move, or are you going to phase it in over time? Look for quick wins; there will be small/simple areas of the application that can serve as a proof of concept for documentation purposes.
• Define the documentation standards and guidelines. What’s the minimum documentation that’s considered acceptable? What will be the “documentation template” to apply to procedures/functions and/or modules? What additional documents should be created? What will be the documentation structure?
• Involve the whole team in the process. It’s not going to be easy to get every programmer on board, so be sure to woo them with the advantages of having comprehensive documentation. Incorporate their input in the guidelines, and review and improve the process at least once a year. They’re both the main consumers and suppliers of the documentation. This makes particular sense if you work with outsourcing or temporary programmers: When they leave, detailed knowledge about the code leaves with them—unless there’s proper documentation.
• Plan time to document as part of the development process. Whenever you’re asked for an estimate for new development, include some time to take care of the necessary documentation. This is the hardest part to “sell” to management, but since the amount of time needed to document the new development will decrease with your experience and the refinement of the documentation process as time goes by, it’ll get easier (eventually).

Documentation that you can benefit from takes time to get right, so you’ll need everybody onboard in this adventure. Try starting small, with a single change request or project, and learn from the experience. You’ll be able to use this proof of concept as leverage to get everyone’s cooperation.

This TechTip concludes the “Write Better Code” subseries, which I hope helped you look at your applications in a new way. The long, hard road to more efficient code, in all its different perspectives, just got a little easier with the strategies and tips described in these articles. Let me know what you think. Share your thoughts, tips, and questions so that we can all benefit from each other’s experience!