Initially used as an analogy to hardwiring electronic circuits, “hard coding” was meant to convey the inflexibility which results from its usage within software design and implementation.
Hard coding, as we know it today, requires a program’s source code to be changed when an external data source has changed. In most cases, it may be more convenient to supply an external tool that allows the parameters that were hard coded to be modified by the user.
For software developers, realizing that some section of software or certain values in software have been hard coded by the original author can prove challenging for another developer to access. In these instances, the developer now responsible for maintaining the software has to determine the causes of reported problems and correct the code. This blog will address where hard coding can and should be used to ensure easy changes down the road.
An “Ah Ha! Oh No!” moment
I’ve often referred to a moment when I stumble upon a section of code that has hard-coded values embedded in it as an “Ah Ha! Oh No!” moment. The “Ah Ha” comes when you have discovered what the issue is. This is quickly followed by the “Oh No”—the realization that what you have just discovered may result in the software requiring a drastic change to remove the hard-coded values or even a new interface that needs to be written to replace the hard-coded values with a more ‘soft coded’ approach.
Consider the following section of code (written in C#) which contains some hard-coded values:
At first glance, you might think that the hard-coded numbers in the above statements could probably be soft coded. In fact, since this section of code is taken from a designer.cs file which is maintained by the designer tool available in Microsoft Visual Studio, these values simply represent numbers that indicate a visual control’s shape and position on a particular screen. The more disturbing hard-coded values here are the ones that are listed in the ‘.AddRange’ statement at the bottom. Since these are values that may need to be changed over time, it would be advisable to place them in a more convenient location in order to be modified in the future. For instance, one could place them in a source code file using a section of code like the following:
The original code would then look like this:
This method makes it easier to later change the values of the hardcoded literals that were used and also makes the code easier to maintain. By concentrating the literal values in one spot, changing these values then changes all occurrences of where they are used in the software. Of course, placing these values into a table in a database and then allowing them to be modified, deleted or to have new values added would be a much more elegant solution. The practicality of doing this needs to be weighed against the necessity for these values to be changed on a regular basis.
When is hard coding OK?
This is a difficult question to answer. For most of us who write software, the simple answer might be never. There are times, however, when it can be okay and maybe even necessary to use hard-coded values in software. For instance, if I have a value that can only ever be one of two values, let’s say 1 or 2, it’s probably permissible to have a statement that looks like the following:
Also, when I am looking at a segment of code like what is shown above, it’s pretty obvious what the intended result was meant to be. So, the rule of thumb for me when I am developing code is to try to put myself in the shoes of the person who comes behind me and whether I would be able to understand the logic or not. I also try to take into account how much time would need to be invested in making a change to this logic if changes were required at a later date.
Although there are search-and-replace tools that can change all occurrences of a given value, 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, hard coding is usually a practice to be avoided.
