Hard coded

By the term hard-coded ( English hardcoded ) is called in the software development application data in the source code of a software are embedded. They are thus defined as constants in the code , although they would normally have to be obtained from external sources such as databases or the user or generated at runtime .

Differentiation from constants

The distinction between hard-coded application data and “normal” constants can be made through the semantic consideration of the value. If it is a value that is reflected in the real world and is also unchangeable there, one speaks of a constant. For example, software could define a constant for days per week with the value 7 . However, if it is a value that will change in the future or at least could change theoretically, one speaks of hard-coded values. It does not matter how probable or practicable a change in this value is.

use cases

A software developer can have various reasons for embedding data directly in the program.

Practical persistence

Hard-coded values ​​are used when it is assumed that they will not change during the lifetime of the version of the software in question. This can be, for example, the URL of the software manufacturer's homepage . This example also makes a dilemma clear: software can only do without hard-coded information to a certain extent. In order to dynamically determine the URL , the manufacturer would have to provide a service, e.g. B. provide in the form of a web service that notifies the program of the current homepage URL on request. In this case, however, the URL of this web service would have to be hard-coded itself.

Protection against manipulation

Hard-coded values ​​can be configuration data such as user name and password (so-called credentials ) or URIs . By embedding the data in the compiled software, manipulation is made significantly more difficult, and in combination with digital signing even made almost impossible.

Testing the software

During the development of a program, the developer may often have to run it himself to test the code. If values ​​are queried from the user during the normal program sequence, the user's inputs are often temporarily hard-coded for the duration of the development in order to save the developer from having to manually enter data (e.g. user name and password of the test account) and thus to reduce the test process accelerate. This practice is simplified by the possibility of conditional compilation, in which different parts of the source code are taken into account by the compiler depending on a so-called compilation constant . This allows the developer to replace the user query code with the hard-coded values ​​in internal test versions. The existence of these values ​​can no longer be determined in the later release version .

Within a mock object , hard-coded values ​​can simulate the result of a function call from other code if this is not (yet) available at the time of the test. For an automated software test , database access can also be simulated using such a mock object. In this case, the results of the queries are hard-coded in the mock object in order to make the test independent of the availability and content of a real database. This procedure is used in particular for module tests when the program code that accesses the database is not the focus of the test. In addition, this can result in great time advantages compared to actually executing the simulated database operation.

When comparing program outputs with previously defined target results, dynamic values ​​(such as time stamps) can pose a problem. In order to enable an uncomplicated comparison, in this case the values ​​normally determined at runtime - for example the current date - are replaced by hard-coded test values.

Hard-coded values ​​as anti-patterns

Depending on the intended use, hard-coded information in a software program can be interpreted as an anti-pattern . In particular, if it is expected that the program will be in use longer than the hard-coded value is valid, dynamic determination of the value is indicated. A program in which the current calendar year is hard-coded will produce incorrect results at the end of the year. For data that should in principle be changeable, but still rarely change, the transfer to a configuration file can be considered.

Creation from constants through later extensions

It is possible that initially harmless constants become problematic hard-coded values ​​through later software extensions.

Example: When implementing the game Mensch ärgere dich nicht, it is initially defined that a game is played with up to 4 players analogous to the traditional board game. A loop that iterates over the list of all players could thus be defined as "from player 1 to 4". If it is later decided that more than 4 players can take part in a game, the originally legitimate constant 4 has now become a hard-coded value. In this special case, it is also referred to as a magic number , since the number 4 cannot be seen without the context of the loop where it comes from. At this point it would be better to replace it with a dynamic check at runtime: "from player 1 to player list . Length ".