Content deleted Content added
No edit summary |
merge from Softcoding |
||
Line 9:
Data that is hard-coded is best suited for unchanging pieces of information, such as [[physical constant|physical constants]], [[Version number|version numbers]], and static text elements.
==Overview==
Line 16:
Hard coding is often required, but can also be considered an [[anti-pattern]].<ref name="Janca2020">{{cite book|author=Tanya Janca|title=Alice and Bob Learn Application Security|url=https://books.google.com/books?id=UT4DEAAAQBAJ&pg=PA15|date=14 October 2020|publisher=Wiley|isbn=978-1-119-68740-5|pages=15–}}</ref> 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
In the context of run-time extensible [[collaborative development environment]]s such as [[Multi-user dungeon|MUD]]s, '''hardcoding''' also refers to developing the core engine of the system responsible for low-level tasks and executing [[Scripting language|scripts]], as opposed to '''softcoding''' which is developing the high-level scripts that get interpreted by the system at [[Execution (computing)|runtime]], with values from external sources, such as [[text files]], [[INI file]]s, preprocessor [[Macro (computer science)|macro]]s, external constants, [[database]]s, [[command-line argument]]s, [[HTTP]] [[Server (computing)|server]] responses, [[configuration file]]s, and [[user input]]. In this case, the term is not pejorative and refers to general development, rather than specifically embedding output data.
Line 28:
== 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 [[sysadmin]] decisions. For example, many installations of [[Microsoft Windows]] use [[Drive letter assignment#Common assignments|drive C:]] as their primary [[hard disk]], but this is not guaranteed.
There was a similar issue with [[microprocessor]]s in early computers, which [[reset (computing)|started execution]] at a fixed [[address space|address]] in memory.
==Startup disk==
Some "[[copy protection|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
This last example shows why hard
==Special folders==
Line 60:
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 [[algorithm]]ic one (even though the hard-coded program might be the output of an algorithmic program).
==Softcoding==
'''Softcoding''' is a [[computer programming|computer coding]] term that refers to obtaining a value or function from some external resource, such as [[text files]], [[INI file]]s, [[preprocessor]] [[Macro (computer science)|macros]], external constants, [[configuration file]]s, [[command-line argument]]s, databases, user input, HTTP server responses. It is the opposite of [[hardcoding]], which refers to coding values and functions in the source code.
===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 number (programming)#Unnamed numerical constants|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]].<ref>[http://thedailywtf.com/Articles/Soft_Coding.aspx Softcoding] from [[The Daily WTF]]</ref>
===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<!-- but generally aren't! -->, 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. <!-- Witness the scores of CMS systems that are so much harder to work with than a bunch of html files in www/data! -->
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]]
▲*[[Closed-source software]]
* [[
* [[Rule of least power]]
* [[Self-modifying code]]
==References==
| |||