12.7. Named Constants

< Free Open Study >

12.7. Named Constants A named constant is like a variable except that you can't change the constant's value once you've assigned it. Named constants enable you to refer to fixed quantities, such as the maximum number of employees, by a name rather than a number� MAXIMUM_EMPLOYEES rather than 1000, for instance. Using a named constant is a way of "parameterizing" your program�putting an aspect of your program that might change into a parameter that you can change in one place rather than having to make changes throughout the program. If you have ever declared an array to be as big as you think it will ever need to be and then run out of space because it wasn't big enough, you can appreciate the value of named constants. When an array size changes, you change only the definition of the constant you used to declare the array. This "single-point control" goes a long way toward making software truly "soft": easy to work with and change. Use named constants in data declarations Using named constants helps program readability and maintainability in data declarations and in statements that need to know the size of the data they are working with. In the following example, you use LOCAL_NUMBER_LENGTH to describe the length of employee phone numbers rather than the literal 7. Good Visual Basic Example of Using a Named Constant in a Data Declaration Const AREA_CODE_LENGTH = 3 Const LOCAL_NUMBER_LENGTH = 7 <-- 1 ... Type PHONE_NUMBER areaCode( AREA_CODE_LENGTH ) As String localNumber( LOCAL_NUMBER_LENGTH ) As String <-- 2 End Type ... ' make sure all characters in phone number are digits For iDigit = 1 To LOCAL_NUMBER_LENGTH <-- 3 If ( phoneNumber.localNumber( iDigit ) < "0" ) Or _ ( "9" < phoneNumber.localNumber( iDigit ) ) Then ' do some error processing ... (1)LOCAL_NUMBER_LENGTH is declared as a constant here. (2)It's used here. (3)It's used here, too. This is a simple example, but you can probably imagine a program in which the information about the phone-number length is needed in many places. At the time you create the program, the employees all live in one country, so you need only seven digits for their phone numbers. As the company expands and branches are established in different countries, you'll need longer phone numbers. If you have parameterized, you can make the change in only one place: in the definition of the named constant LOCAL_NUMBER_LENGTH. As you might expect, the use of named constants has been shown to greatly aid program maintenance. As a general rule, any technique that centralizes control over things that might change is a good technique for reducing maintenance efforts (Glass 1991). Further Reading For more details on the value of single-point control, see pages 57�60 of Software Conflict (Glass 1991). Avoid literals, even "safe" ones In the following loop, what do you think the 12 represents? Visual Basic Example of Unclear Code For i = 1 To 12 profit( i ) = revenue( i ) -- expense( i ) Next Because of the specific nature of the code, it appears that the code is probably looping through the 12 months in a year. But are you sure? Would you bet your Monty Python collection on it? In this case, you don't need to use a named constant to support future flexibility: it's not very likely that the number of months in a year will change anytime soon. But if the way the code is written leaves any shadow of a doubt about its purpose, clarify it with a well-named constant, like this: Visual Basic Example of Clearer Code For i = 1 To NUM_MONTHS_IN_YEAR profit( i ) = revenue( i ) -- expense( i ) Next This is better, but, to complete the example, the loop index should also be named something more informative: Visual Basic Example of Even Clearer Code For month = 1 To NUM_MONTHS_IN_YEAR profit( month ) = revenue( month ) -- expense( month ) Next This example seems quite good, but we can push it even one step further by using an enumerated type: Visual Basic Example of Very Clear Code For month = Month_January To Month_December profit( month ) = revenue( month ) -- expense( month ) Next With this final example, there can be no doubt about the purpose of the loop. Even if you think a literal is safe, use named constants instead. Be a fanatic about rooting out literals in your code. Use a text editor to search for 2, 3, 4, 5, 6, 7, 8, and 9 to make sure you haven't used them accidentally. Simulate named constants with appropriately scoped variables or classes If your language doesn't support named constants, you can create your own. By using an approach similar to the approach suggested in the earlier Java example in which enumerated types were simulated, you can gain many of the advantages of named constants. Typical scoping rules apply: prefer local scope, class scope, and global scope in that order. Cross-Reference For details on simulating enumerated types, see "If Your Language Doesn't Have Enumerated Types" in the previous section, Section 12.6. Use named constants consistently It's dangerous to use a named constant in one place and a literal in another to represent the same entity. Some programming practices beg for errors; this one is like calling an 800 number and having errors delivered to your door. If the value of the named constant needs to be changed, you'll change it and think you've made all the necessary changes. You'll overlook the hard-coded literals, your program will develop mysterious defects, and fixing them will be a lot harder than picking up the phone and yelling for help.

< Free Open Study >