Hard coding

Hard coding (also, hard-coding or hardcoding) refers to the software development practice of embedding 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.

Considered an anti-pattern or Bad Thing, 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.

The term "hard-coded" was coined in 1990 by R. Galichon (then a Programmer/Analyst at Mobil Oil headquarters in Fairfax, VA). 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.

Hardcoding and piracy

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.

Fixed installation path

If a Windows program is programmed to assume it is always installed to C:Program FilesAppname and someone tries to install it to a different drive for space or organization reasons, it may fail to install or to run after installation. This problem might slip through, since the vast majority of people prefer installation to the default drive and directory and testing might fail to turn it up. 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 the , but this is not the case.

This is similar to the microprocessors in early computers, that 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.

tartup disk

Some "copy-protected" programs look for a particular file on a floppy disk on startup to verify that they are not unauthorized copies. If the computer is updated to a newer machine, which doesn't have a floppy drive, the program now can't be run, since the floppy disk can't be inserted.

The last example shows why hard coding is a bad idea even when it seems like it would work completely at the time. In the 1980s and 1990s a PC without a floppy drive would likely have seemed unthinkable, but they are becoming more common today. A program hard coded in that manner 15 years ago could face serious problems if no update were made. Again, many companies will not be concerned if their programs can't be run 15 years later, and it may even be a form of planned obsolescence.

pecial Folders

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:

Profile path

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, or if the program is executed on Windows Vista, that stores the user profile in the C:Users"Username" folder. The proper way to get it is to call the GetUserProfileDirectory function. Another assumption that developers often make is assuming that the profile is located on a local hard disk.

My Documents folder path

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, 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.

olution

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. A common program bug that may arise in this situation is for some of the appearances of the value to be modified, but not all of them. This can give rise to subtle bugs that are difficult to find and may remain within the program for a long period of time. Similar problems may occur if the same hard-coded value has several different meanings, for example an array of 6 elements and a minimum input string length of 6. A programmer may mistakenly change all instances of the value (most often using automated search-and-replace functionality of an editor) rather than all instances with a specific meaning. 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.)

Hard coding in competitions

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 case when possible number of inputs is limited, contestants may consider using an if-clause or case-clause to identify all the possible inputs and output the hard coded data directly from the program instead of processing the input.