Cure

---

How often have you been asked to work with code that contains hardcoded values? Perhaps even you have written some of these hardcoded values. As these values sit there, particularly those that are duplicated multiple times, they represent errors waiting to happen. These values must be removed from the code before they can cause any problems, or possibly any more problems.

When to Refactor

The simple answer is that all hardcoded values should be removed from the code, but this can be naïve in the face of schedule pressure. Therefore, it is beneficial to consider in what order to tackle this removal. This will leave you with the least risky hardcoded values if schedule pressure forces you to leave some of the hardcoded values in the code.

The highest priority should be given to any strings that must be localized, unless you are working under some strange project that has no possibility of being internationalized. Even if the application is not initially targeted for the international market, it is a good idea to prepare for this eventuality. Otherwise, it can be a tedious process later when all the strings must be extracted from various assets and code to a central file for localization.

Of equal importance are any values that might change when ported to other platforms or languages. These are mostly made up of user interface values, and are less likely than strings to be hardcoded. It is nonetheless a wise idea to ensure that they are not hardcoded and are easily editable to produce different builds for the application’s target platforms or possible future platforms.

Only slightly less important are any values that are likely to be tweaked repeatedly. Once again, many of these are likely to be user interface values, but there might be other values as well. By removing these values from the code, the tweaking process can occur at a much faster rate and does not require the assistance of a programmer. This will often save both time and money for the project.

Context Highlighting

Before the hardcoded values can be removed, they must be found. Utilities for finding the values are not commonly available today, but there are still tools that can help with this process. One such utility is built in to many modern code editors, which allow you to highlight the source code text according to the context of each value. In other words, different constructs of the programming language can be rendered in different colors and fonts to make them more distinguishable. For our purposes, the most interesting of these are the highlighting of numbers and strings (Figure 8.2). By choosing a bright noticeable color and bold font, these values can be made to stand out against the surrounding code. This is an excellent way, while browsing through the code, to spot hardcoded values that need refactoring.

Figure 8.2: Context highlighting is used to make strings and numbers more visible in Microsoft Visual Studio.

Context highlighting can also be applied to code that is printed out. This provides a much better medium if there is a large amount of code to browse, but color printing is still not common so font highlighting must be used in many cases (Figure 8.3). This process can still be somewhat time consuming, so if you are pressed for time but still need to remove hardcoded values, then context highlighting will be of less help. One editor tool that can still help is regular expression searches. With a little bit of work, a regular expression that finds number and strings while ignoring other language constructs can be constructed. This is particularly useful if the search can be applied across multiple files. This limits the amount of code that must be visited, and combined with context highlighting can provide a fast and effective way to catch most hardcoded values.

Figure 8.3: By adding underlining to strings and numbers in IntelliJ’s IDEA, they become more visible even when printed.

Collection

Removing the hardcoded values from the code is best done as a two-step process. First, collect each value into a global variable or other variable with a wide scope. Many languages offer a method of marking this variable as unchanging, such as const in C++ and final in Java, and always available, such as static in both C++ and Java. These modifiers can be applied for both readability and performance reasons.

Preferably, one central location can be used initially or at least only a few collection locations. As similar values appear in the collection, they can be examined to determine if they represent the same concept. Do not be tempted to combine values simply because they are equal. Later, one of the values might require a change while the other should remain the same. Combining different constants that happen to have the same value will make this difficult.

Run Time vs. Compile Time

Once all the hardcoded values have been collected and collated, a decision can be made about their final resting place. The first major decision that must be made for each value is whether the value should be in an asset file or remain in the code. Most values should be moved to an asset file, but there might be occasions when the value cannot change except under the most unlikely circumstances. For example, the value for ( is extremely unlikely to change. Because the extra work will provide little chance of future gain, it is reasonable to leave these values in the code. Nonetheless, they should still be placed in meaningful locations and retain a readable name, thus making the code that uses the value more readable.

The majority of the values can then be moved to an asset file. These values are then read in, often at initialization time, and can be placed in a variable with the same name that was used to collect the value. This limits the amount of code that must be changed in each step of the process, thus reducing the amount of error that can occur. As always, testing after each change is advisable to ensure that the changes have not altered the values of any calculations and therefore the behavior of the application.

---