This subseries of RPG Academy focus on ways to improve your code’s efficiency, readability, and maintainability. In other words, it will help you write better code.

While there’s no “magic bullet,” it’s possible to enhance your code with proper naming conventions, organization, and documentation strategies. It’s true that some of these strategies are little more than common sense, but others will require changing a few (I dare say ages-old) habits. One good example is the way we write—or don’t write—documentation. As you’ll see on this and the next TechTips, there are many areas of improvement when the objective is writing clean, crisp code that’s easy on the eyes and easy for you or your successors to maintain.

Instead of going straight to the documentation topic, which I’m sure everybody is curious about, let me start with something else that makes code easier to read: naming conventions.

When the Name Says It All: The Importance of Naming Conventions

Picking names for the “things” in our code is too often based on external factors such as approaching deadlines, old habits, and bad company standards (or lack of standards), just to name a few. This turns code that should read almost like a story into something cryptic and time-consuming. That’s why proper naming conventions must be applicable to everything with a name, from variables to functions, modules, and service programs.

Naming Variables Guidelines: Procedure and Work Variable Prefixes

Let’s start with variables. You certainly agree that X, Y, and Z are not ideal names for variables, right? Even if variables are simply going to be used for a specific, contained task, it’s important to give their names meaning. Using prefixes that identify the variable’s purpose is a good way to start. Personally, I like to use short prefixes directly related to the purpose of the variable. This TechTip and the next one present the prefixes I strongly recommend, with an example for each of them.

Consider function Cvt_USD_to_EUR, shown below, which converts U.S. dollars to euros, as the name implies. Let’s say the P_USD_Amt input parameter is not defined with VALUE or CONST in the prototype definition:

*-----------------------------------------------------------------------*

*   Convert USD to Eur at the current exchange rate    

*-----------------------------------------------------------------------*

P Cvt_USD_to_Eur...

P                 B                   EXPORT                      

D                 PI           11p 2                          

D P_USD_Amt                   11p 2

Now, imagine that the currency conversion process inside the function is using P_Usd_Amt as a work variable, thus changing its value. When the function ends and control returns to the calling program, the input parameter value (in the calling program) might be different!

It’s important to isolate the parameters in separate variables, as well as to create proper interfaces in your functions (by correctly defining input parameters, to use proper names, and so on). This is how the procedure interface should be defined:

*-----------------------------------------------------------------------*

*   Convert USD to Eur at the current exchange rate    

*-----------------------------------------------------------------------*

P Cvt_USD_to_Eur...

P                 B                   EXPORT                      

D                 PI           11p 2                          

D P_USD_Amt                   11p 2 Value

It’s also important to use work variables—not parameter variables—for intermediate steps or calculations, which brings us to the next prefix on the list.

Use W_ for work variables. This prefix signals that the variable is an intermediate step or temporary storage for something. It’s important to use a few of these in more complex pieces of code to facilitate debugging and improve readability, because function nesting can get very cryptic and hard to follow.

Let’s keep using the currency conversion function as an example. You’d call it like this:

W_Eur_Amt = Cvt_USD_to_Eur(P_USD_Amt);

Note that I’m using a P_ variable for the parameter, but I’m using a W_ variable to store the result of the call. I mentioned that function nesting can become cryptic, remember? Here’s a “light” example that could easily be found in many applications:

IP = Cost(Cvt_USD_to_Eur(P_USD_Amt): Cvt_Lb_to_Kg(P_Lb) : DF);

I tried not to complicate things too much here, but even this simple example would be very hard to follow if it weren’t for the function names. It would be even harder to debug because of all the function nesting and cryptic variable names.

Now, let’s apply the simple principles I’ve explained so far (and a few others I’ll explain later) to our example:

W_Eur_Amt = Cvt_USD_to_Eur(P_USD_Amt);

W_Converted_Weight = Cvt_Lb_to_Kg(P_Lb);

// Calculate Item shipment price, based on weight and delivery fee

W_Item_Shipmnt_Price = Clc_Shpmnt_Cost(W_Eur_Amt         :

                                       W_Converted_Weight:

                                       W_Delivery_Fee   );

Isn’t it clearer like this? In addition to proper variable names and prefixes, I threw in a few other things, like commenting and indentation. The code immediately becomes more readable and maintainable, albeit a bit longer.

The next TechTip will continue to discuss variable prefixes, and it will also cover a technique I mentioned in a previous article: named indicators. Until then, feel free to ask questions or share your own prefix scheme in the comments section below!