Stop! Don’t hardcode that value!

April 21, 2004

In the world of programming, the absolute worst thing to do is to hardcode a value into a function.

As defined at: http://whatis.techtarget.com/

“In computer programming or text markup, to hardcode (less frequently, hard code) is to use an explicit rather than a symbolic name for something that is likely to change at a later time. Such coding is sometimes known as hardcode (noun) and it is more difficult to change if it later becomes necessary. In most programming languages, it is possible to equate a symbol with a particular name (which may also represent a number) value. If the name changes, the symbol stays the same and only the equate line of code needs to be changed to reflect the new name. When the program is recompiled, the new name is picked up wherever the symbol occurs in the code. Although there are search-and-replace tools that can change all occurrences of a given name, program code is very unforgiving in case a small error is introduced, and it is safer to have a single place in which such a change can be made. For this reason, hardcoding is usually a practice to be avoided.

Hardcode is also sometimes used in describing more difficult programming languages such as C or C++ rather than such “softcode” languages as Visual Basic.”

I see it time and time again – hardcoded application settings.  Things like: array limits, min / max limits, database settings, timeout values, etc.

When it comes to creating a flexible, re-usable application, one of the worst things you can do is hardcode settings like where to put the log file, or how long to wait for the XML feed to return, or even what component to instantiate to handle file type X.

Why do programmers hardcode things that should be configurable?  There are generally two reasons.  The first is inexperience.  An inexperienced programmer may not recognize when a value should be placed in a configuration file.  The second is time. The boss is breathing down your neck, the due date was yesterday and there’s simply no time to pay attention to good programming practices.

Now, the first reason is easily remedied with time, experience, and research.  The second reason is rather inexcusable with today’s environments, cookies, databases, .ini files, and registry capabilities.  There are built-in functions to read and write values with ease.  Reading a setting from a storage location is child’s play.  There are so many options available to developers now, it’s exciting.

XML, in particular, improves the saving of configuration values significantly.  In contrast, .ini files are poor in the organization department. They are simple flat files, with a few groupings to separate the settings.  The Windows registry, while better than .ini files in the organization department, are a pain to maintain.   So XML, with the hierarchy of the registry, the easy distribution of .ini files (and better), and with sorting and query capabilities, is a definitely a preferred choice.  No wonder .net is using it as it’s primary means of saving settings.

In conclusion, there really is no valid reason for neglecting to use configurable settings.  To hardcode settings, is to severely limit the flexibility of your application.  I don’t know about you, but I hate scanning through lines of code to change all the places where someone hardcoded the value “25” as per the original specifications that are now changing (big surprise). 

The best applications are configurable, organized and commented.