Hungarian Notation

Using Constants

A constant is much like a variable; you create a name and assign it a value. However, unlike a variable, a constant is given its value at design time, and this value cannot be changed at run time. You should always use constants in place of magic numbers, for reasons I'll discuss in this section.

Note

When you hard-code a string in a procedure, the effect is similar to that of using magic numbers. All the reasons for eliminating magic numbers also apply to eliminating hard-coded strings; if you know the value at design time, use a constant rather than hard-coding the text or the number.

 

Magic Numbers Are Prone to Data-Entry Problems

One of the critical problems with magic numbers is that you can easily mistype a number, transposing its digits. When you type the number 10876, for instance, it's not at all difficult to mistakenly type 10867 or 18076. In contrast to the way it handles variables and reserved words, the compiler in Microsoft Visual Basic .NET takes no issue with transposed or incorrect numbers it's happy to use whatever magic number you supply. Sometimes the problems caused by a simple mistake don't surface immediately, and when they do they can appear as random miscalculations that are difficult to pinpoint. When you use a constant in place of a magic number, Visual Basic .NET checks the validity of the constant at compile time. If the constant does not exist, Visual Basic .NET tells you so and refuses to compile. This eliminates the problem of inaccurately typed numbers; as long as the single constant has the correct value, all the code that uses that constant will use the correct value as well.

Warning

If you don't include the Option Explicit statement within the Declarations section of a module and you mistype a constant name, Visual Basic .NET implicitly declares a variable with the incorrect name of the constant, causing inaccurate results. This is just one more reason to explicitly declare your variables. See Chapter 5, "Variables," for more information on explicit vs. implicit variable declaration. Using Option Strict is the best option, in which case you'll have to specify a data type for each constant you create.

 

Magic Numbers Are Difficult to Update

Another serious drawback to magic numbers is that they're difficult to keep updated. Say you're developing a financial application and the current mortgage interest rate is 7.25 percent. Also assume that this value is hard-coded in a number of procedures that perform calculations based on the interest rate. What do you do when the rates change (which they do regularly)? You could perform a global search and replace, but that exposes your code to errors. Another loan rate used within the application might also have the value 7.25. If you perform a global search and replace on 7.25 percent, you'll change that loan rate as well. If you manually change each value in the code, you risk transposing or otherwise mistyping the new values, and you'll also likely miss changing one or more references. A selective search and replace with a confirmation on each change would be time-consuming. If you used a constant instead of hard-coding the value, you would simply change the value once (in the constant's declaration), and every line of code that uses the mortgage interest rate instantly uses the new, updated rate.

Constants Make Code Easier to Read

A by-product of using constants to create more error-free code is code that is much more readable. Generally, magic numbers are anything but intuitive. They might be obvious to you, but they can be difficult for others to decipher. By intelligently naming your constants, the code that uses those constants becomes a bit more self-documenting and a lot easier to read. Consider the following two code statements. Which makes the most sense to you?

Magic numbers:

decInterestAmount = (decLoanAmount * 0.06) / 12 

Named constants:

decInterestAmount = _       CDec((decLoanAmount * c_sngInterestRate) / c_intMonthsInTerm) 

One last note on constants: it's quite acceptable to give constants higher scope, unlike when you use variables, where it's highly advisable to reduce scope. As a matter of fact, you should never create the same constant twice within an application. If you find that you're duplicating a constant, move the original declaration to a higher scope until the constant becomes available to all procedures that need it. Also, consider placing all your global constants in the Declarations section of the same module, thereby facilitating easier maintenance.