Gourt Home::Gourt :: Hard code
To hard code or hard coding (also, hard-code/hard-coding, hardcode/hardcoding) refers to the software development practice of embedding output 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.
Hardcoding also refers to developing the compiled components of a MUD, writing the C/C++ code that runs the core engine as opposed to softcoding which is developing scripts which get interpreted by the MUD at runtime. In this case, the practice refers to general development, rather than specifically embedding output data.
Examples and utilities of hard code
Product code
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 ceases to exist, the program will fail to work.It is considered a serious mistake for software developers to do this, since websites frequently disappear or get rearranged. However, some developers may ignore these concerns due to arrogance about the future existence of the website or company, or to apathy about what happens to the users of the program in the distant future.
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 organization reasons, it may fail to install or 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 to not fix the installation path of a program, since the default installation path is different in different languages, and because not every Windows computer has a C: drive.
Startup disk
Some "copy-protected" programs look for a particular file on a floppy disk on startup to verify that they are 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.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.
Profile path
Some Windows programs hardcode the profile path to developer-defined locations such asC:\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. 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 toProfilePath\My Documents. The program would work on most computers, but 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.
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. 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 switch-clause to identify all the possible inputs and output the hard coded data directly from the program instead of processing the input.
"Hard code"