The Leading Educational Resource for IT Professionals

RPG Academy: Write Better Code - Commenting and Documenting Strategies


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;



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.


About the Author: Rafael Victoria-Pereira 

Also in MC Press Articles

Customer (Citizen) Identity and Access Management


As a major trend in the IDM sector, consumerization has become easier and exponentially more important. Digital transformation will literally put a significant segment of the SME market out of business and propel a significant number of SMEs to new levels of prosperity.

Continue Reading →

Federated Authentication – there is no Plan B


Federated authentication is essential for businesses. It's the only way to effectively manage external access to business systems and it's absolutely necessary in order to manage authentication to SaaS apps. if you don't want to expose your identity records to potential compromise.

Continue Reading →

Access Control – RBAC & ABAC


Access Control is the core of the identity and access management task. Once we have correctly provisioned user data into the enterprise’s identity service we need to leverage it for access control. The vast majority of organizations use role-based access control, but increasingly, access control based on attributes is gaining traction.

Continue Reading →