Hardcode in ontwikkeling: wat het is, risico's en hoe te vermijden

Wat betekent „vastpinnen“ en „hardcoden“

Hardcoden (vastpinnen) – een specifieke waarde in de programmacode inbouwen zodanig dat voor wijziging ervan de broncode moet worden bewerkt en de applicatie opnieuw moet worden gecompileerd. De metafoor „vastpinnen“ geeft de essentie precies weer: de waarde is stevig vastgezet en kan alleen met moeite van de code worden losgemaakt.

Voorbeeld van hardcode – een server-URL die als string direct in de body van een functie is geschreven. Als de server naar een ander adres verhuist, moet de ontwikkelaar de string in de code vinden, wijzigen, de applicatie opnieuw bouwen en een release uitrollen. In een applicatie met correcte architectuur zou zo'n URL zijn ondergebracht in een configuratiebestand, omgevingsvariabele of configuratiedienst.

De term „vastpinnen“ heeft een meer emotionele lading: het benadrukt dat de waarde stevig is ingevoegd zonder mogelijkheid tot snelle vervanging. In de Nederlandstalige omgeving worden beide uitdrukkingen gebruikt als volledige synoniemen met een negatieve connotatie. Soms wordt hardcode ironisch „een constante die naar een aparte constante uit een constante is verplaatst“ genoemd.

Waarom hardcode als anti-patroon wordt beschouwd

Hardcode is een anti-patroon omdat het de principes van onderhoudbaarheid, testbaarheid en uitbreidbaarheid van code schendt. In code waar waarden „vastgepind“ zijn, vereist elke wijziging van omgeving, ontwerp of logica handmatig zoeken en vervangen in de bronbestanden. Dit verhoogt het risico op fouten en vertraagt de ontwikkeling.

Laten we de concrete gevolgen van hardcode bekijken aan de hand van een typische mobiele applicatie. Als de afstand van alle knoppen is ingesteld met een getal in de code in plaats van via een bron – dan vereist een ontwerpwijziging het vinden en vervangen van alle voorkomens. Als de endpoint-URL hard is gecodeerd – is schakelen tussen omgevingen (dev, stage, prod) onmogelijk zonder hercompilatie.

Voorbeeld van slechte hardcode

Een functie die magische getallen en hard gecodeerde strings gebruikt, is een klassiek voorbeeld van hardcode. Na een maand herinnert de auteur zich niet meer wat 18, 0.07 en 2.5 betekenen. Na een jaar – durft niemand in het team deze getallen te wijzigen uit angst de logica te breken. Het verplaatsen van waarden naar benoemde constanten maakt de code zelfdocumenterend.

// Slecht: magische getallen en strings
fun calculatePrice(base: Double): Double {
    val tax = base * 0.07
    val tip = base * 0.15
    val discount = if (base > 100) 10 else 0
    return base + tax + tip - discount
}

Impact op testen

Een hardgecodeerde database-URL staat niet toe dat tests op een lokale in-memory database worden uitgevoerd. De ontwikkelaar moet een volledige server opzetten of de code aanpassen voor het testen. Het verplaatsen van configuratie uit de code lost het probleem op: tests gebruiken testparameters, productie gebruikt productieparameters en de code verandert niet.

Wanneer hardcode gerechtvaardigd is: uitzonderingen op de regel

Hardcode is een anti-patroon, maar er bestaan legitieme uitzonderingen waarbij een hard gecodeerde waarde niet alleen is toegestaan, maar zelfs de voorkeur verdient. De grens loopt langs de as van veranderlijkheid: als een waarde nooit of bijna nooit verandert in de levenscyclus van de applicatie, kan deze worden gehardcode. Als deze op zijn minst potentieel kan veranderen – verplaats deze dan naar de configuratie.

Wiskundige en natuurkundige constanten – Pi, zwaartekrachtversnelling, aantal milliseconden in een seconde – zijn veilig voor hardcode. Ze worden gedefinieerd door de natuur of standaarden en zullen niet veranderen. Groottes van constante arrays die door specificatie zijn gedefinieerd, kunnen ook hard worden vastgezet, maar met een opmerking over de oorsprong van het getal.

Voorbeeld van gerechtvaardigde hardcode

Het aantal milliseconden in een seconde is een stabiele constante gedefinieerd door de tijdstandaard. Het heeft geen zin om deze naar een config te verplaatsen, omdat deze nooit zal veranderen. Zelfs dergelijke constanten kunnen echter beter met een begrijpelijke naam worden gedeclareerd, zodat de code geen „magische getallen“ bevat: schrijf in plaats van 1000 MILLISECONDS_IN_SECOND.

// Gerechtvaardigde hardcode: stabiele constanten
private const val MILLIS_IN_SECOND = 1000
private const val LOGIN_TIMEOUT_SECONDS = 30

fun formatDuration(ms: Long): String {
    val seconds = ms / MILLIS_IN_SECOND
    return "${seconds} sec."
}

Alternatieven voor hardcode: configs, ENV, DI

Er zijn verschillende beproefde methoden om hardcode te vermijden, elk geschikt voor een specifiek type waarde. De keuze van het alternatief hangt af van hoe vaak de waarde verandert en wie deze wijzigt: de ontwikkelaar, de devops of de eindgebruiker.

Configuratiebestanden

Voor server-URL's, API-sleutels en feature flags gebruik je configuratiebestanden in JSON-, YAML- of TOML-formaat. Op Android is dit build.gradle met buildConfigField of res/values/config.xml. Op iOS – Info.plist of xcconfig. Configs worden samen met de applicatie gebouwd, maar kunnen verschillen voor verschillende buildschema's.

Omgevingsvariabelen

Voor geheimen (tokens, wachtwoorden) en omgevingsparameters gebruik je omgevingsvariabelen. Ze komen niet in de repository terecht en kunnen verschillen op dev-, stage- en prod-servers. In mobiele ontwikkeling worden omgevingsvariabelen vaak geëmuleerd via Xcode-buildschema's of build flavors in Gradle.

Applicatiebronnen

Strings, kleuren, afmetingen, afbeeldingen moeten worden ondergebracht in bronbestanden: strings.xml op Android, Localizable.strings op iOS, ARB-bestanden in Flutter. Dit vereenvoudigt lokalisatie, aanpassing aan verschillende schermen en donkere modus. Het wijzigen van een string in bronnen vereist geen herschrijving van code.

<!-- Android: res/values/strings.xml -->
<resources>
    <string name="app_name">MyApp</string>
    <string name="api_base_url">https://api.example.com</string>
</resources>

Dependency Injection (DI)

Voor services en providers gebruik je Dependency Injection via Dagger, Hilt of Koin op Android, Swinject op iOS. DI-frameworks maken het mogelijk implementaties ter plekke te vervangen – voor tests, voor verschillende omgevingen, voor verschillende gebruikers. Dit is het hoogste abstractieniveau, waarbij het „vastpinnen“ van de waarde wordt vervangen door injectie van buitenaf.

Hoe gehardcode code te refactoren

Refactoring van hardcode is het proces van het verplaatsen van hard gecodeerde waarden naar configuratie of bronnen. Dit is een van de veiligste refactoring-operaties, mits deze methodisch wordt uitgevoerd. De hieronder beschreven volgorde is geschikt voor elke taal en platform.

Stap 1: vind alle magische getallen en strings

Zoeken kan via IDE (Search in Project) of met een script. Zoek naar strings, URL's, numerieke literals, afmetingen, time-outs. Bijzondere aandacht voor herhalende waarden: als hetzelfde getal op vijf plaatsen voorkomt, is dit een kandidaat voor verplaatsing naar een constante. Gebruik grep of de ingebouwde zoekfunctie van IDEA / Xcode.

Stap 2: vervang door benoemde constanten

Maak voor elke gevonden waarde een constante met een betekenisvolle naam. Groepeer constanten per module of klasse. De naam moet uitleggen wat de waarde betekent, niet hoe deze wordt gebruikt: API_TIMEOUT, niet TIMEOUT_30. Na vervanging mag geen enkel getal in de code zonder uitleg blijven.

// Voor: magisch getal 0.4
let cardHeight = screenHeight * 0.4

// Na: benoemde constante
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

Stap 3: verplaats naar configuratie of bronnen

Als de waarde kan veranderen tussen builds of omgevingen – verplaats deze dan naar een configuratiebestand of applicatiebronnen. Gebruik voor strings lokalisatiebestanden. Voor URL's – build config of xcconfig. Voor afmetingen – bronbestanden (dimens.xml op Android). Controleer dat de applicatie correct compileert en werkt na het verplaatsen.

Stap 4: schrijf een test

Schrijf na de refactoring een test die controleert dat de configuratie correct wordt geladen en de waarden overeenkomen met de verwachtingen. Als iemand in de toekomst de config wijzigt, wijst de test op de afwijking. Een configuratietest is een snelle en betrouwbare manier om regressie te voorkomen.

Stap 5: verwijder duplicaten

Controleer na het verplaatsen naar de config of alle plaatsen waar de oude waarde werd gebruikt naar een enkele bron verwijzen. Verwijder uitgecommentarieerde code en oude constanten die niet meer worden gebruikt. Rond de refactoring af met een commit met een bericht dat beschrijft welke waarden waarheen zijn verplaatst.