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
D January C 1
D February C 2
D March C 3
/free
%occur(SqlFieldsDS) = January;
/end-free
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
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
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
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online