Hard coding (also, hard-coding or hardcoding) refers to the software development practice of embedding what may, perhaps only in retrospect, be regarded as input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.
Contents |
Considered an anti-pattern, hard coding requires the program's source code to be changed any time the input data or desired format changes, when it might be more convenient to the end user to change the detail by some means outside the program.
Hard coding is sometimes required. Programmers may not have a dynamic user interface solution for the end user worked out but must still deliver the feature or release the program. This is usually temporary but does resolve in, a short term sense, the pressure to deliver the code. Later, softcoding is done to allow a user to pass on parameters that give the end user a way to modify the results or outcome.
The term "hard-coded" was coined in 1990 by R. Galichon (then a Programmer/Analyst at Mobil). The term was used as an analogy to hardwiring circuits - and was meant to convey the inflexibility which results from its usage within software design and implementation. In the context of run-time extensible collaborative development environments such as MUDs, hardcoding also refers to developing the core engine of the system responsible for low-level tasks and executing scripts, as opposed to softcoding which is developing the high-level scripts that get interpreted by the system at runtime. In this case, the term is not pejorative and refers to general development, rather than specifically embedding output data.
As an anti-piracy measure, software developers may hardcode a unique serial number directly into a program. A program that has a unique serial number may regularly check its maker's website to verify that it hasn't been blacklisted as pirated. If that website moves or the company goes out of business, this may cause the program to fail, even for perfectly legal users, if that check is programmed to fail when no response is received.
On the opposite case, a software cracker may hardcode a valid serial number to the program or even prevent the executable from asking the user for it, allowing illegal copies to be redistributed without the need of entering a valid serial, thus sharing the same key for every copy, if one has been hardcoded.
If a Windows program is programmed to assume it is always installed to C:\Program Files\Appname and someone tries to install it to a different drive for space or organizational reasons, it may fail to install or to run after installation. This problem might not be identified in the testing process, since the vast majority of people prefer installation to the default drive and directory and testing might not include another installation directory. However it is advisable for programmers and developers not to fix the installation path of a program, since the default installation path is different in different natural languages, and different computers may be configured differently. It is a common assumption that all computers running Microsoft Windows have the primary hard disk labelled as drive C:, but this is not the case.
There was a similar problem with the microprocessors in early computers, which were built to expect the computer's initial program code to start at the address 0 of the memory pool (or at another fixed address). This was a failsafe layout for units designed for a narrow field of purposes, but lacked much expandability.
Some "copy-protected" programs look for a particular file on a floppy disk or flash drive on startup to verify that they are not unauthorized copies. If the computer is replaced by a newer machine, which doesn't have a floppy drive, the program that requires it now can't be run, since the floppy disk can't be inserted.
This last example shows why hard-coding may turn out to be impractical even when it seems at the time that it would work completely. In the 1980s and 1990s the great majority of PCs were fitted with at least one floppy drive, but floppy drives later fell out of use. A program hard-coded in that manner 15 years ago could face problems if not updated.
Some Windows operating systems have so called Special Folders which organize files logically on the hard disk. There are problems that can arise involving hardcoding:
Some Windows programs hardcode the profile path to developer-defined locations such as C:\Documents and Settings\Username. This is the path for the vast majority of Windows 2000 or above, but this would cause an error if the profile is stored on a network or otherwise relocated. The proper way to get it is to call the GetUserProfileDirectory function or to resolve the %userprofile% environment variable. Another assumption that developers often make is assuming that the profile is located on a local hard disk.
Some Windows programs hardcode the My Documents folder path to ProfilePath\My Documents. The program would work on most computers, but on localized versions of Windows (for example in Italian version My Documents folder is translated as Documenti), or if the My Documents folder is redirected using Folder Redirection in Group Policy in Windows 2000 or above a serious error would occur. The proper way to get it is to call the SHGetFolderPath function.
An indirect reference, such as a variable inside the program called "FileName", could be expanded by accessing a "browse for file" dialogue window, and the program code would not have to be changed if the file moved.
Hard coding is especially problematic in preparing the software for translation to other languages.
In many cases, a single hard-coded value, such as an array size, may appear several times within the source code of a program. This would be a magic number. This may commonly cause a program bug if some of the appearances of the value are modified, but not all of them. Such a bug is hard to find and may remain in the program for a long time. A similar problem may occur if the same hard-coded value is used for more than one parameter value, eg an array of 6 elements and a minimum input string length of 6. A programmer may mistakenly change all instances of the value (often using an editor's search-and-replace facility) without checking the code to see how each instance is used. Both situations are avoided by defining constants, which associate names with the values, and using the names of the constants for each appearance within the code.
One important case of hard coding is when strings are placed directly into the file, which forces translators to edit the source code to translate a program. (gettext is a tool that permits strings to be left in files, but lets translators translate them without changing the source code; it effectively de-hard codes the strings.)
In computing competitions such as the International Olympiad in Informatics, contestants are required to write a program with specific input-output pattern according to the requirement of the questions.
In cases where the possible number of inputs is finite, a contestant might consider using an approach that maps all possible inputs to their correct outputs. This program would be considered a hard-coded solution as opposed to an algorithmic one.