In that past few weeks, I have had several (sometimes heated) discussions regarding constants. Mostly, the discussions have revolved around when and how to use them. In the interest of time, I'll cut to the conclusions that we came to and spare the reader the mind-numbingly boring discussions. (You can thank me later.) One conclusion that we came to was that there are approximately as many theories on how use constants as there are developers (possibly more!).

The problem is in the implementation. Different people have different ideas on how constants should be implemented. I'm not going to try to persuade you to use them or not use them, and I'm not going to try to dictate how to use them. The goal here is just to steer you away from some of the pitfalls.

Identifying Constants

How to name and easily identify a constant is a hotly debated question among developers. There are all sorts of "standards." Below is a partial list of the naming conventions I've encountered most frequently:

MY_CONSTANT (All caps)
cMyConstant (Preceding "c")
QCMDEXC  (Name matches value, e.g., QCMDEXC = "QCMDEXC")

Any and all of these can be combined to make other conventions, such as cQCMDEXC.

There are really only two pitfalls regarding name conventions. First, a naming convention is valuable only if you always adhere to it. All too often, I see code with a combination of all three of the above naming conventions, which just makes the naming conventions useless. The second pitfall has to do with using constant names that match the value. I admit that this practice makes sense in some cases, but more often than not, it doesn't. Take the following examples (from actual code I have seen!):

Example 1: What Not to Do

Example 2: A Better Choice

In the first example, it is clear enough what is happening. But why use a constant at all in this case? In the second example, it is again clear what is happening. However, using the constant with the descriptive name "January" gives further clarification to both what is occurring and what the probable contents of the data structure are.

Don't Cloud the Issue

Sometimes developers get carried away. I know it's hard to believe, but it's true. Sometimes we (myself included) take a good idea and go way too far with it. There are too many "bad" examples to try to list them here. However, I have a thumb rule that seems to work pretty well. It goes like this: If using a constant makes the code more readable and easier to maintain, then use it. Otherwise, you are just making the code more complicated for no reason.

Obvious and Not-So-Obvious Suggestions

So now that I have said that I won't advocate using constants, I am going to do just that. Here are some obvious examples of where constants make the most sense:

• All Boolean type values—e.g., *ON, *OFF, "1", "0", "Y", "N". These are well-accepted as constants called YES, NO, TRUE, and FALSE.
• AID bytes for all the functions keys—e.g., F1 = x'31', F2 = x'32', etc. This makes interactive program code much easier to read. You could even take it a step further and define specific key functions, like so: F1_HELP = x'31'.
• Maximum index values for arrays and/or data structures—e.g., MaxOccurence = 12
• Any "flag" values—These are those small fields used in files to "flag" attributes of some sort, e.g., file fields for employee-type values: EXEMPT = "X" and HOURLY = "H".

And here are some that are perhaps not so obvious:

• Change message file IDs to be more obvious in code—e.g., Object_Not_Found = 'CPF9801' or SQL_Duplicate_Key = -803.
• Common problem causing characters in character strings—e.g., SLASH = "/" or QUOTE = "''"

Enough of my pontificating. To recap, pick a naming convention and stick to it. Then, be judicious in your use of constants.

Jeff Olen is once again following the wild geese and leaving all his friends at Costco Corporate. He would like to bid a them fond farewell and wish them well. He has re-joined the ranks of the software engineering mercenaries and can now be found mainly on airplanes or in airports. If you can’t find him there, you can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Jeff Olen is a super-spy now but keeps his cover identity intact by working for video game studios on the East Coast. So when he’s not out killing members of ISIS or rescuing refugees, you can find him playing Wolfenstein II or testing the new Fallout 76 releases at his beach house in Costa Rica. In any case, he can’t be reached. You can email his cat at This email address is being protected from spambots. You need JavaScript enabled to view it.. She will pass on your message…if she feels like it.

---

MC Press books written by Jeff Olen available now on the MC Press Bookstore.

		The IBM i Programmer’s Guide to PHP Get the scoop on how PHP can—and should—be deployed on IBM systems. List Price $79.95 Now On Sale