Hard code

To hard code or hard coding refers to the software development practice of embedding data directly into the source code of a computer program or other executable object, instead of obtaining that data from external sources such as a configurations file or command-line parameters. One important case of hard coding is when strings are placed directly in 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.)

Considered an Anti-pattern or bad idea, it requires that the program code be changed any time that the data changes, when it might be more convenient to the end user to change the detail by some means outside the program.

= Examples =

A program that has a unique product code always checks its maker s website to be sure that it hasn t been blacklisted as pirated. If the corporation changes its site layout or its domain name, or if it goes bankrupt and its site is pulled, the program will fail to work.

If a program is programmed to assume it is always installed to C:Program FilesAppname and someone tries to installs it to a different drive for space or organization concerns, it may fail to install or run after installation.

A program always looks for a particular file on a floppy disk on startup to verify that it s not pirated. 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.

== Explanation ==

The first example could be seen and prevented, since websites frequently disappear or get rearranged. However, these concerns may be ignored due to arrogance about the future existence of the website or company, or apathy about what happens to the users of the program in the distant future. The second example might slip through, since the vast majority of people install to the default drive and directory and testing might fail to turn it up. 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 or early 1990s a computer without a floppy drive would likely seem 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.

= Solution =

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 (programming). 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. This situation is avoided by defining a constant in a single place, which associates a name with the numeric value, and using the name of the constant for each appearance within the code.