Hartkodiert
Mit dem Begriff hartkodiert (englisch hard coded) bezeichnet man in der Softwareentwicklung Anwendungsdaten, die in den Quelltext einer Software eingebettet sind. Sie sind somit im Code als Konstanten definiert, obwohl sie normalerweise von externen Quellen wie Datenbanken oder dem Benutzer bezogen oder zur Laufzeit generiert werden müssten.
Abgrenzung zu Konstanten
Die Unterscheidung von hartkodierten Anwendungsdaten und „normalen“ Konstanten kann durch die semantische Betrachtung des Wertes erfolgen. Handelt es sich um einen Wert, der sich in der realen Welt widerspiegelt und dort ebenfalls unveränderlich ist, spricht man von einer Konstanten. Beispielsweise könnte eine Software eine Konstante für Tage pro Woche mit dem Wert 7 definieren. Handelt es sich jedoch um einen Wert, der sich in Zukunft ändern wird oder zumindest theoretisch ändern könnte, spricht man von hartkodierten Werten. Dabei ist es unerheblich, wie wahrscheinlich oder praktikabel eine Änderung dieses Wertes ist.
Anwendungsfälle
Ein Softwareentwickler kann verschiedene Gründe haben, Daten direkt in das Programm einzubetten.
Praktische Persistenz
Hartkodierte Werte werden verwendet, wenn angenommen wird, dass sie sich während der Einsatzdauer der fraglichen Version der Software nicht ändern. Das kann zum Beispiel die URL der Homepage des Software-Herstellers sein. An diesem Beispiel wird auch ein Dilemma deutlich: eine Software kann nur bis zu einem gewissen Grad auf hartkodierte Angaben verzichten. Um die URL dynamisch zu ermitteln, müsste der Hersteller einen Dienst z. B. in Form eines Webservices bereitstellen, der dem Programm auf Anfrage die aktuelle Homepage-URL mitteilt. In diesem Fall müsste allerdings die URL dieses Webservices wiederum selbst hartkodiert werden.
Schutz vor Manipulation
Bei hartkodierten Werten kann es sich um Konfigurationsdaten wie Benutzername und Passwort (sog. Credentials) oder URIs handeln. Durch die Einbettung der Daten in die kompilierte Software wird eine Manipulation maßgeblich erschwert, und in Kombination mit digitaler Signierung sogar nahezu unmöglich gemacht.
Testen der Software
Während der Entwicklung eines Programms muss dieses unter Umständen häufig vom Entwickler selbst ausgeführt werden, um den Code zu testen. Werden dabei im normalen Programmablauf Werte vom Benutzer abgefragt, so werden für die Dauer der Entwicklung die Eingaben des Benutzers oft temporär hartkodiert, um dem Entwickler die immer wiederkehrende manuelle Eingabe der Daten (beispielsweise Benutzername und Passwort des Testaccounts) zu ersparen und den Testprozess so zu beschleunigen. Vereinfacht wird diese Praxis durch die Möglichkeit der bedingten Kompilierung, bei der in Abhängigkeit einer sogenannten Kompilier-Konstante unterschiedliche Teile des Quellcodes vom Compiler berücksichtigt werden. Dies erlaubt es dem Entwickler, in internen Testversionen den Code zur Benutzer-Abfrage durch die hartkodierten Werte zu ersetzen. Das Vorhandensein dieser Werte ist in der späteren Release-Version nicht mehr festzustellen.
Innerhalb eines Mock-Objekts können hartkodierte Werte das Ergebnis eines Funktionsaufrufs von anderem Code simulieren, wenn dieser zum Zeitpunkt des Tests (noch) nicht zur Verfügung steht. Für einen automatisierten Softwaretest kann auch ein Datenbank-Zugriff durch ein solches Mock-Objekt simuliert werden. In diesem Fall sind dann die Ergebnisse der Abfragen im Mock-Objekt hartkodiert, um den Test von der Verfügbarkeit und dem Inhalt einer realen Datenbank unabhängig zu machen. Dieses Vorgehen findet insbesondere bei Modultests Anwendung, wenn der Programmcode, der die Datenbank-Zugriffe durchführt, nicht im Testfokus steht. Zusätzlich können sich hierbei große Zeitvorteile gegenüber einer tatsächlichen Ausführung der simulierten Datenbankoperation ergeben.
Beim Vergleich von Programmausgaben mit vorab definierten Soll-Ergebnissen können dynamische Werte (beispielsweise Zeitstempel) ein Problem darstellen. Um einen unkomplizierten Vergleich zu ermöglichen, werden in diesem Fall die normalerweise zur Laufzeit ermittelten Werte – also zum Beispiel das aktuelle Datum – durch hartkodierte Testwerte ersetzt.
Hartkodierte Werte als Anti-Pattern
Je nach Verwendungszweck kann eine hartkodierte Angabe in einem Software-Programm als Anti-Pattern aufgefasst werden. Insbesondere wenn zu erwarten ist, dass das Programm länger im Einsatz ist als der hartkodierte Wert Gültigkeit hat, ist die dynamische Ermittlung des Wertes angezeigt. Ein Programm, in welchem das aktuelle Kalenderjahr hartkodiert ist, wird nach Ablauf des Jahres falsche Ergebnisse liefern. Für Daten, die prinzipiell veränderlich sein sollten, sich aber dennoch selten ändern, kann die Auslagerung in eine Konfigurationsdatei in Erwägung gezogen werden.
Entstehung aus Konstanten durch spätere Erweiterungen
Es ist möglich, dass aus zunächst unbedenklichen Konstanten durch spätere Erweiterungen der Software problematische hartkodierte Werte werden.
Beispiel: Bei der Umsetzung des Spiels Mensch ärgere dich nicht ist zunächst definiert, dass eine Partie analog zum traditionellen Brettspiel mit bis zu 4 Spielern gespielt wird. Eine Schleife, die über die Liste aller Spieler iteriert, könnte also als „von Spieler 1 bis 4“ definiert werden. Wird später entschieden, dass mehr als 4 Spieler an einer Partie teilnehmen können, ist aus der ursprünglich legitimen Konstante 4 in diesem Moment ein hartkodierter Wert geworden. In diesem speziellen Fall wird auch von einer magischen Zahl gesprochen, da der Zahl 4 ohne den Kontext der Schleife nicht anzusehen ist, woher sie kommt. An dieser Stelle wäre es besser, sie durch eine dynamische Prüfung zur Laufzeit zu ersetzen: „von Spieler 1 bis Spielerliste.Länge“.