--- title: "Was ist Hardcoding? Warum hart codierte Werte ein Problem sind" description: "Was bedeutet Hardcoding? Warum hartcodierte Werte in der Programmierung Probleme verursachen und wie du sie vermeidest. Mit Beispielen erklärt." canonical_url: "https://robocitrus.com/blog/was-ist-hardcoding" last_updated: "2026-07-05T22:51:01.476Z" --- Wenn du Programmiercode liest oder mit Entwicklern sprichst, fällt irgendwann der Begriff "Hardcoding". Klingt nach einem bewussten Stil, ist aber meistens ein Fehler. Ich erkläre dir, was Hardcoding bedeutet, warum hard coded Werte Probleme verursachen und wann es tatsächlich okay ist. --- ## Video: API-Keys im Code? Warum das ein Problem ist --- ## Kurz zusammengefasst - **Hardcoding** bedeutet, feste Werte direkt in den Quellcode zu schreiben, statt sie konfigurierbar zu machen - Hardcodierte Werte machen Code schwer wartbar, unsicher und unflexibel - Typische Beispiele: fest eingetippte Passwörter, API-URLs, Dateipfade oder "magische Zahlen" - Die Alternative: Umgebungsvariablen, Konfigurationsdateien und Konstanten - In bestimmten Fällen (mathematische Konstanten, feste Enums) ist Hardcoding völlig in Ordnung --- ## Was bedeutet Hardcoding? Hardcoding (auch Hard Coding oder Hard-Coding) beschreibt die Praxis, einen festen Wert direkt in den Programmcode zu schreiben, anstatt ihn von aussen konfigurierbar zu machen. Ein hardcodierter Wert steht also wörtlich im Code und lässt sich nur ändern, indem man den Code selbst bearbeitet. Hardcoded bedeutet im Grunde: "Dieser Wert ist fest eingebaut und kann nicht von aussen verändert werden." Ein einfaches Beispiel in JavaScript: ```javascript // Hardcoded: Die Farbe steht fest im Code function getHeaderColor() { return '#FF5733'; } // Besser: Die Farbe kommt aus einer Konfiguration function getHeaderColor(config) { return config.headerColor; } ``` Im ersten Fall ist die Farbe hard coded. Willst du sie ändern, musst du den Code anfassen, neu kompilieren und neu deployen. Im zweiten Fall liest du die Farbe aus einer Konfiguration. Du kannst sie jederzeit anpassen, ohne eine Zeile Code zu ändern. Das ist die Hardcoding Definition in einem Satz: Ein Wert, der direkt im Quellcode steht, statt aus einer externen Quelle zu kommen. ## Ein Alltagsvergleich Stell dir vor, du kaufst ein neues Navigationsgerät. Aber statt einer Adresseingabe hat jemand die Adresse "Musterstrasse 42, Berlin" fest einprogrammiert. Egal wo du hin willst, das Navi fährt immer zur Musterstrasse 42. Um ein anderes Ziel einzugeben, müsstest du das Gerät aufschrauben und die Platine umprogrammieren. Klingt absurd? Genau das passiert beim Hardcoding in der Programmierung. Statt dem Nutzer (oder dem System) die Möglichkeit zu geben, einen Wert einzugeben, wird er fest eingebaut. Wie ein GPS, das nur eine einzige Adresse kennt. Ein konfigurierbares Navi dagegen lässt dich jede beliebige Adresse eintippen. Das ist der Unterschied zwischen hard coded und konfigurierbar. ## Beispiele für Hardcoding Hier sind vier typische Fälle, die mir in der Praxis ständig begegnen. Ich zeige sie in JavaScript und Dart, weil das die Sprachen sind, mit denen ich täglich arbeite. Wenn du den Unterschied zwischen der Sprache im [Frontend und Backend](/blog/frontend-vs-backend) verstehen willst, schau dir meinen Artikel dazu an. ### 1. Hardcoded API-URL ```javascript // Hardcoded: URL steht fest im Code async function fetchUsers() { const response = await fetch('https://api.meineapp.de/v2/users'); return response.json(); } // Besser: URL aus Umgebungsvariable async function fetchUsers() { const response = await fetch(`${process.env.API_BASE_URL}/users`); return response.json(); } ``` Das Problem: Wenn du von der Entwicklungsumgebung auf Production wechselst, musst du den Code ändern. Oder schlimmer: Du vergisst es und deine Live-App schickt Anfragen an den Testserver. ### 2. Hardcoded Passwort ```javascript // Hardcoded: Zugangsdaten direkt im Code (niemals tun!) async function connectDatabase() { const connection = await db.connect({ host: 'localhost', user: 'admin', password: 'geheim123' }); return connection; } // Besser: Zugangsdaten aus Umgebungsvariablen async function connectDatabase() { const connection = await db.connect({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD }); return connection; } ``` Hard coded Passwörter im Quellcode sind ein Sicherheitsrisiko. Jeder, der Zugriff auf den Code hat (und das sind bei Open-Source-Projekten alle), sieht deine Zugangsdaten. Sogar wenn du das Passwort später änderst, bleibt es in der Git-Historie sichtbar. ### 3. Magic Numbers ```dart // Hardcoded: Was bedeutet 86400? Future refreshToken() async { await Future.delayed(Duration(seconds: 86400)); await getNewToken(); } // Besser: Benannte Konstante const int secondsPerDay = 86400; Future refreshToken() async { await Future.delayed(Duration(seconds: secondsPerDay)); await getNewToken(); } ``` 86400 ist die Anzahl der Sekunden in einem Tag. Aber das wissen nur Leute, die es ausgerechnet haben. Solche "magischen Zahlen" machen Code unleserlich. In einem halben Jahr weisst du selbst nicht mehr, warum da 86400 steht. Hardcoded Zahlen ohne Kontext sind ein klassisches Code-Smell. ### 4. Hardcoded Dateipfade ```javascript // Hardcoded: Pfad funktioniert nur auf deinem Rechner function loadConfig() { return readFile('/Users/max/projects/meineapp/config.json'); } // Besser: Relativer Pfad oder Umgebungsvariable function loadConfig() { return readFile(path.join(process.env.APP_ROOT, 'config.json')); } ``` Absolute Dateipfade, die auf einen bestimmten Rechner zugeschnitten sind, brechen auf jedem anderen System. Dein Kollege hat den Code geklont und nichts funktioniert, weil sein Benutzername nicht "max" ist. ## Warum ist Hardcoding ein Problem? Hardcoding verursacht in der Praxis immer wieder die gleichen Probleme: **Wartungsalptraum.** Wenn sich ein Wert ändert (und Werte ändern sich immer), musst du jede Stelle im Code finden und manuell anpassen. Hast du die API-URL an 15 Stellen hart codiert, musst du alle 15 finden. Vergisst du eine, hast du einen Bug. **Sicherheitsrisiko.** Hardcoded Passwörter, API-Keys und Zugangsdaten im Code sind ein Einfallstor. Sie landen in Git-Repositories, in Backups, auf den Rechnern aller Teammitglieder. Ein einziger Leak und deine Datenbank steht offen. **Keine Flexibilität.** Hard coded Werte funktionieren genau in einer Umgebung. Willst du zwischen Development, Staging und Production wechseln, musst du den Code jedes Mal ändern. Das ist fehleranfällig und nervt. **Schwer testbar.** Wenn eine Funktion eine fest eingebaute API-URL hat, kannst du sie nicht mit einem Mock-Server testen, ohne den Code zu ändern. Konfigurierbare Werte machen deine Tests flexibler und zuverlässiger. ## Die Alternative: Konfigurierbare Werte Die Lösung für Hardcoding sind konfigurierbare Werte. Es gibt verschiedene Ansätze, die du je nach Situation kombinieren kannst. ### Umgebungsvariablen (.env) Der Klassiker. Du speicherst Werte in einer `.env`-Datei, die nicht ins Git-Repository kommt: ```bash # .env API_BASE_URL=https://api.meineapp.de DB_PASSWORD=sicheres_passwort ``` ```javascript // Im Code const apiUrl = process.env.API_BASE_URL; ``` ### Konfigurationsdateien Für komplexere Einstellungen eignen sich JSON- oder YAML-Dateien: ```json { "theme": { "primaryColor": "#FF5733", "maxUploadSize": 10485760 } } ``` ### Benannte Konstanten Für Werte, die sich im Code nicht ändern, aber einen Namen brauchen: ```dart const double taxRate = 0.19; const int maxRetries = 3; const String defaultLanguage = 'de'; ``` Das ist kein Hardcoding im negativen Sinne. Der Wert steht zwar im Code, hat aber einen sprechenden Namen. Der Unterschied: Eine Konstante sagt dir, was der Wert bedeutet. Ein hardcodierter Wert steht einfach da, ohne Kontext. ### Dependency Injection In grösseren Projekten übergibst du Abhängigkeiten von aussen: ```dart class ApiClient { final String baseUrl; ApiClient({required this.baseUrl}); Future> fetchUsers() async { final response = await http.get(Uri.parse('$baseUrl/users')); return parseUsers(response.body); } } // Verwendung final client = ApiClient(baseUrl: Environment.apiUrl); ``` So kannst du im Test einen Mock-Server und in Production den echten Server nutzen, ohne den Code zu ändern. ## Wann ist Hardcoding okay? Nicht jeder feste Wert im Code ist automatisch schlecht. Es gibt Fälle, in denen Hard Coding völlig in Ordnung ist: **Mathematische Konstanten.** Pi ist 3.14159. Das ändert sich nicht. Auch die Anzahl der Sekunden pro Minute (60) oder die Bytes pro Kilobyte (1024) sind feste Werte, die du hardcoden kannst, idealerweise als benannte Konstante. **Enum-Werte.** Status-Codes wie `active`, `inactive`, `pending` sind Teil deiner Geschäftslogik. Die stehen im Code, weil sie zum Code gehören. **Wirklich fixe Werte.** Wenn ein Wert sich garantiert nie ändert und nur an einer Stelle verwendet wird, ist Hardcoding pragmatisch. Overengineering ist auch keine Lösung. Die Faustregel: Wenn du dir vorstellen kannst, dass sich ein Wert in Zukunft ändern könnte oder an mehreren Stellen gebraucht wird, mach ihn konfigurierbar. ## Hardcoding in der App-Entwicklung In der mobilen App-Entwicklung tauchen hardcodierte Werte besonders oft auf, und hier fallen sie dir schneller auf die Füsse als anderswo. ### Hardcoded API-Keys in Apps ```dart // Hardcoded: Jeder kann den Key aus der App extrahieren class PaymentService { final String apiKey = 'sk_live_abc123geheim'; Future processPayment(double amount) async { // ... } } // Besser: Key kommt vom eigenen Backend class PaymentService { Future getApiKey() async { final response = await http.get( Uri.parse('${Environment.apiUrl}/config/payment-key'), headers: {'Authorization': 'Bearer ${userToken}'}, ); return jsonDecode(response.body)['key']; } } ``` Mobile Apps können dekompiliert werden. Ein hard coded API-Key in einer veröffentlichten App ist so, als würdest du deinen Haustürschlüssel unter die Fussmatte legen. Jeder, der weiss wo er suchen muss, findet ihn. Deshalb: Sensible Keys gehören auf den Server, nicht in den App-Code. ### Hardcoded Farben statt Themes ```dart // Hardcoded: Farben überall im Code verstreut class LoginButton extends StatelessWidget { @override Widget build(BuildContext context) { return ElevatedButton( style: ElevatedButton.styleFrom( backgroundColor: Color(0xFF2196F3), foregroundColor: Color(0xFFFFFFFF), ), onPressed: () {}, child: Text('Login'), ); } } // Besser: Theme nutzen class LoginButton extends StatelessWidget { @override Widget build(BuildContext context) { return ElevatedButton( style: ElevatedButton.styleFrom( backgroundColor: Theme.of(context).colorScheme.primary, foregroundColor: Theme.of(context).colorScheme.onPrimary, ), onPressed: () {}, child: Text('Login'), ); } } ``` Wenn du Farben hart codierst und der Kunde sagt "Ich will doch lieber Grün statt Blau", musst du jede einzelne Farbangabe im Code suchen und ändern. Mit einem Theme änderst du eine Stelle und die ganze App passt sich an. Besonders relevant wird das, wenn du einen Dark Mode anbietest. ### Hardcoded Strings statt Lokalisierung ```dart // Hardcoded: Funktioniert nur auf Deutsch Text('Willkommen zurück!') // Besser: Lokalisiert Text(AppLocalizations.of(context)!.welcomeBack) ``` Willst du deine App später in anderen Sprachen anbieten, sind hardcodierte Strings ein echtes Problem. Du musst jeden einzelnen Text finden und extrahieren. Wenn du von Anfang an Lokalisierung nutzt, ist eine neue Sprache nur noch eine Übersetzungsdatei. ## Wie finde ich hardcodierte Werte in meinem Code? Es gibt ein paar praktische Wege: - **Code-Suche**: Suche nach typischen Mustern wie `http://`, `https://`, IP-Adressen oder auffälligen Zahlen - **Linter-Regeln**: Viele Linter (wie ESLint oder dart analyze) haben Regeln, die vor Magic Numbers oder hartcodierten Strings warnen - **Code Reviews**: Ein zweites Paar Augen findet oft Hardcoding, das dir selbst nicht auffällt - **Statische Analyse**: Tools wie SonarQube scannen deinen Code automatisch auf problematische Muster ## Fazit Hardcoding ist einer dieser Fehler, die am Anfang harmlos wirken. Der Code funktioniert ja. Aber langfristig sammelst du technische Schulden an, die dich irgendwann einholen. Jeder hard coded Wert ist eine kleine Zeitbombe: Irgendwann muss er geändert werden, und dann wird es aufwendig. Die gute Nachricht: Es ist nicht schwer, es richtig zu machen. Umgebungsvariablen, Konfigurationsdateien und benannte Konstanten lösen 90% aller Hardcoding-Probleme. Der Aufwand ist gering, aber du sparst dir auf Dauer jede Menge Ärger. Mein Tipp: Wenn du einen Wert in deinen Code tippst, frag dich kurz: "Könnte sich das jemals ändern?" Wenn ja, mach es konfigurierbar. Dein zukünftiges Ich wird dir danken. ## Häufig gestellte Fragen Nein. Mathematische Konstanten, Enum-Werte und wirklich fixe Werte dürfen hart codiert sein. Problematisch wird es bei Werten, die sich ändern könnten: URLs, Zugangsdaten, Farbwerte, Texte. Die Faustregel: Wenn ein Wert sich ändern könnte oder an mehreren Stellen vorkommt, mach ihn konfigurierbar. Nutze die Suche deiner IDE, um nach typischen Mustern zu suchen: URLs (http://), IP-Adressen, auffällige Zahlen oder Strings in Anführungszeichen. Linter und statische Analysetools wie SonarQube helfen ebenfalls. Am effektivsten sind aber regelmässige Code Reviews im Team. Eine Konstante hat einen sprechenden Namen, der erklärt, was der Wert bedeutet (z.B. `const maxRetries = 3`). Ein hardcodierter Wert steht ohne Kontext direkt im Code (z.B. eine nackte `3` in einer Schleife). Konstanten sind eine bewusste Designentscheidung, Hardcoding ist meistens Nachlässigkeit. Nein, das ist sogar Best Practice. Wenn du Werte als benannte Konstanten in einer zentralen Datei sammelst, hast du einen klaren Überblick und musst bei Änderungen nur eine Stelle anfassen. Das Gegenteil von Hardcoding ist nicht "keine Werte im Code", sondern "Werte organisiert und benannt im Code".