Hard coding
This article needs additional citations for verification. (May 2021) |
Hard coding (also hard-coding or hardcoding) is the software development practice of embedding data directly into the
Hard-coded data typically can only be modified by editing the source code and
Data that is hard-coded is best suited for unchanging pieces of information, such as
Softcoded data, on the other hand, encodes arbitrary information through
Overview
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.[1]
Hard coding is often required, but can also be considered an anti-pattern.[2] 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 initially used as an analogy to hardwiring circuits - and was meant to convey the inflexibility that results from its usage within software design and implementation. In the context of run-time extensible
Hardcoding and backdoors
Hardcoding credentials is a popular way of creating a
Hardcoding and DRM
As a
On the opposite case, a software cracker may hard-code a valid serial number to the program or even prevent the executable from asking the user for it, allowing unauthorized copies to be redistributed without the need of entering a valid number, thus sharing the same key for every copy, if one has been hard-coded.
Fixed installation path
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 average user installs to the default drive and directory and testing might not include the option of changing the installation directory. However, it is advisable for programmers and developers not to fix the installation path of a program, since the default installation path depends on the operating system, OS version, and
There was a similar issue with microprocessors in early computers, which started execution at a fixed address in memory.
Startup disk
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.
Special folders
Some Windows operating systems have so called
Profile path
Some Windows programs hard code 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.
My Documents folder path
Some Windows programs hardcode the path to My Documents
as ProfilePath\My Documents
. These programs would work on machines running the English version, but on localized versions of Windows this folder normally has a different name. For example, in Italian versions the My Documents
folder is named Documenti. My Documents
may also have been relocated using Folder Redirection in Group Policy in Windows 2000 or above. The proper way to get it is to call the SHGetFolderPath
function.
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
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. (There is a tool called gettext
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 rare cases where the possible number of inputs is small enough, 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 (even though the hard-coded program might be the output of an algorithmic program).
Softcoding
Softcoding is a
Programming practice
Avoiding hard coding of commonly altered values is good programming practice. Users of the software should be able to customize it to their needs, within reason, without having to edit the program's source code. Similarly, careful programmers avoid magic numbers in their code, to improve its readability, and assist maintenance. These practices are generally not referred to as softcoding.
The term is generally used where softcoding becomes an anti-pattern. Abstracting too many values and features can introduce more complexity and maintenance issues than would be experienced with changing the code when required. Softcoding, in this sense, was featured in an article on The Daily WTF.[3]
Potential problems
At the extreme end, soft-coded programs develop their own poorly designed and implemented scripting languages, and configuration files that require advanced programming skills to edit. This can lead to the production of utilities to assist in configuring the original program, and these utilities often end up being 'softcoded' themselves.
The boundary between proper configurability and problematic soft-coding changes with the style and nature of a program. Closed-source programs must be very configurable, as the end user does not have access to the source to make any changes. In-house software and software with limited distribution can be less configurable, as distributing altered copies is simpler. Custom-built web applications are often best with limited configurability, as altering the scripts is seldom any harder than altering a configuration file.
To avoid softcoding, consider the value to the end user of any additional flexibility you provide, and compare it with the increased complexity and related ongoing maintenance costs the added configurability involves.
Achieving flexibility
Several legitimate design patterns exist for achieving the flexibility that softcoding attempts to provide. An application requiring more flexibility than is appropriate for a configuration file may benefit from the incorporation of a scripting language. In many cases, the appropriate design is a domain-specific language integrated into an established scripting language. Another approach is to move most of an application's functionality into a library, providing an API for writing-related applications quickly.
See also
- Closed-source software
- Firmware
- Inner-platform effect
- Rule of least power
- Self-modifying code
References
- ISBN 978-0-201-79429-8.
- ISBN 978-1-119-68740-5.
- ^ Softcoding from The Daily WTF