Usually, programmers don’t comment their code appropriately, for a variety of reasons: “I don’t have the time,” “My code speaks for itself,” and so on. Mostly, they simply hate doing it. Let me try to refute these excuses with practical strategies and tools.

Written by Rafael Victória-Pereira

As I’ve said throughout this series, a procedure’s name and parameter list should be enough for the programmer to understand the objective of that piece of code. However, there are times when this is not enough: complex procedures, generic names, uninspired input/output parameter names…and the list goes on and on. The next section of this TechTip will help you in the process of creating proper documentation for your newly created procedures and functions, with a few tips of what you should and shouldn’t do.

Documenting Procedures and Functions

It’s best to make a rule (and stick to it) to always start by creating a succinct description of the procedure and documenting the parameter list. This description should include what goes in, what comes out, what’s mandatory, and so on. So, instead of forcing whoever needs to use (or modify) your procedure’s code to read and understand it, top to bottom, make a habit of writing a brief description of the procedure and its parameters in the procedure’s header. Something similar to this will do:

//-----------------------------------------------------------------

// Cvt_USD_to_Eur: Convert US Dollars to Euros at the current

// exchange rate.

// This function accepts an USD Amount (11, 2) as mandatory input parm

// And returns an EUR Amount (11, 2)

//-----------------------------------------------------------------

DCL-PR Cvt_USD_to_Eur   PACKED(11 : 2);

     // Input parameter: Amount in US Dollars

P_USD_Amt         PACKED(11 : 2) Value;

END-PR;

You might want to embellish it a bit: reserve a description line for each parameter, and create fixed sections like “Inputs,” “Outputs,” “Return” (for functions), and so on. It’s also a good idea to create a template in a separate source member and copy it to the source you’re currently working on every time you need to create a new procedure.

Doing this in the header has two advantages. First, it helps you keep the procedure documentation updated, since it’s right above the procedure interface, and any major change in the functionality or the parameters will have to start here. Second, when you need to understand what the code does, you’ll (hopefully) start from the top. But that’s just the header! Documenting the procedure’s internals properly is equally important.

Comment First, Code Later!

When writing a new procedure, it’s usually useful to jot down a few ideas before writing code, even if the functional analysis is thorough. Most programmers do this on a piece of paper (or a functional analysis document’s margins), but we all do it, right? I’m not saying that you’re doing it wrong—I’m just saying you’re doing it in the wrong place. If you write those ideas or generic operations (which will compose the procedure’s internal workings) in the procedure’s body as lines of comment describing each relevant operation, you can map out the work and then start writing the code between the comments. When you’re finished, go over it again, and add additional explanations, or simply turn the generic idea into something that you’ll understand the next time you read the procedure.

Remember how that complex piece of code works? You might not in a couple of months, so there’s no harm in explaining something particularly complex in a couple of comment lines! We’ve all been there: You solve a complicated problem in a few short, dense lines of code and then forget about it. Sometime later, when you have to review it, you have no idea what it does.

The solution is to explain in comment lines, as if you’re explaining to a five-year-old, what you did there. It’s not a waste of time; it’s an investment that will pay for itself over and over again, when you or another programmer needs to understand how that piece of code does what it does.

Free-format has the added advantage of letting you write comments alongside the code, so use this feature to comment in situ the most complex parts of the code. I’ve mentioned before the importance of meaningful variable names, but it’s never too much to stress the importance of a good balance between self-documenting code (code that reads like English, or at least similar) and actual documentation. It’s true that free-format’s longer names help, but good—even though brief—comments are also important.

The next TechTip will conclude this discussion on documentation by presenting some tools to help you document and a few guidelines to help you define your documentation strategy. Until then, share your experience, doubts, methods, and more on the documentation topic in the comments sections below.