Waarom wij ELSE vermijden in een IF statement

Binnen softwareontwikkeling zijn er van die kleine keuzes die op het eerste gezicht onbelangrijk lijken, maar op lange termijn een enorm verschil maken in leesbaarheid, onderhoudbaarheid en foutgevoeligheid van code.

Eén daarvan is het gebruik van else statements.

Bij Qlic proberen we else zoveel mogelijk te vermijden. Niet omdat het “verboden” is, maar omdat code zonder onnodige else statements vaak duidelijker, veiliger en makkelijker uitbreidbaar is.

In deze blog leggen we uit waarom.

Het probleem met ELSE

Veel developers leren programmeren met klassieke structuren zoals deze:

if ($user->isAdmin()) {
    return $this->showAdminDashboard();
} else {
    return $this->showUserDashboard();
}

Functioneel klopt dit prima, maar de else voegt hier eigenlijk niets toe. Want zodra de eerste return uitgevoerd wordt, stopt de functie al. De else is dus overbodig. Dezelfde code kan veel eenvoudiger:

if ($user->isAdmin()) {
    return $this->showAdminDashboard();
}

return $this->showUserDashboard();

Dat lijkt een klein verschil, maar in grotere codebases stapelen deze patronen zich op en precies daar ontstaan problemen.

Waarom code zonder ELSE beter leesbaar is

Softwareontwikkeling draait niet alleen om code schrijven. Het draait vooral om code begrijpen. Vaak leest een developer tientallen keren vaker code dan dat hij nieuwe code schrijft. Daarom is voorspelbaarheid belangrijk. Wanneer je werkt met early returns in plaats van diepe if/else constructies:

• wordt de flow van de code duidelijker
• voorkom je onnodige nesting
• blijft de “happy flow” beter zichtbaar
• kun je sneller scannen wat er gebeurt

Vergelijk deze twee voorbeelden.

Met ELSE

if ($order->isPaid()) {

    if ($order->hasStock()) {

        if ($order->isValidated()) {
            $this->processOrder($order);
        } else {
            throw ValidationException::class;
        }

    } else {
        throw OutOfStockException::class;
    }

} else {
    throw PaymentRequiredException::class;
}

Zonder ELSE

if (! $order->isPaid()) {
    throw PaymentRequiredException::class;
}

if (! $order->hasStock()) {
    throw OutOfStockException::class;
}

if (! $order->isValidated()) {
    throw ValidationException::class;
}

$this->processOrder($order);

De tweede versie leest vrijwel als een checklist. Dat maakt debugging en onderhoud aanzienlijk eenvoudiger.

Minder nesting = minder complexiteit

Elke extra if, else, switch of nested condition verhoogt de cognitieve belasting van code. Een developer moet continu onthouden in welke scope hij zit, welke voorwaarden al gecontroleerd zijn of welke paden nog mogelijk zijn. Door else te vermijden hou je code platter. Dat klinkt simpel, maar heeft grote voordelen zoals:

• minder bugs
• sneller reviewen
• eenvoudiger testen
• makkelijker refactoren

Zeker in grotere Laravel-projecten of enterprise software zie je vaak dat diepe nesting uiteindelijk leidt tot “spaghetti code”en dat begint meestal klein.ELSE maakt uitbreiden vaak lastiger. Een ander probleem ontstaat wanneer businesslogica groeit. Wat begint met twee scenario’s, worden er al snel drie, vier of tien.

Bijvoorbeeld:

if ($user->isAdmin()) {
    //
} else {
    //
}

Een paar maanden later:

if ($user->isAdmin()) {
    //
} elseif ($user->isManager()) {
    //
} elseif ($user->isSupport()) {
    //
} else {
    //
}

En uiteindelijk verandert dit in complexe conditionele logica die moeilijk te volgen is.
Vaak is dat een signaal dat de verantwoordelijkheid eigenlijk ergens anders hoort.

Bijvoorbeeld:

• policies
• strategy patterns
• action classes
• state machines
• polymorfisme

Door minder snel naar else te grijpen, dwing je jezelf automatisch om beter na te denken over de structuur van je applicatie.Early returns maken intentie expliciet.
Wij gebruiken daarom vaak zogenaamde “guard clauses”. Dat zijn vroege controles die direct stoppen wanneer iets niet klopt.

Bijvoorbeeld:

if (! $user) {
    return;
}

if (! $user->isActive()) {
    return;
}

if (! $user->hasSubscription()) {
    return;
}

$this->startTrial($user);

De intentie van de code is direct duidelijk:

“Alleen als alles klopt, gaan we verder.”

Dat voorkomt verborgen logica diep in een functie. Is ELSE dan altijd slecht? Nee er zijn situaties waarin else prima leesbaar is. Bijvoorbeeld bij simpele binaire logica:

$value = $isProduction
? 'production'
: 'local';

Of wanneer beide takken echt gelijkwaardig zijn
Het doel is dus niet:
“Gebruik nooit else", maar “Gebruik else alleen wanneer het écht iets toevoegt.” In veel gevallen blijkt dat niet zo te zijn.

Waarom dit belangrijk is in teams

In kleine projecten lijkt dit soort stijlkeuzes soms overdreven.
Maar binnen grotere teams maken consistente patronen enorm verschil.

Goede code moet namelijk:

• voorspelbaar zijn
• snel leesbaar zijn
• makkelijk overdraagbaar zijn
• veilig aangepast kunnen worden

Door duidelijke afspraken te maken over structuur en codekwaliteit voorkom je technische schuld op lange termijn.
Het vermijden van onnodige else statements is daar een klein, maar effectief onderdeel van.

Clean code draait om eenvoud

De beste code is meestal niet de slimste code.
Het is de code die een andere developer direct begrijpt zonder uitleg.

Door te kiezen voor:

• early returns
• guard clauses
• minder nesting
• duidelijke flows

maak je software met deze specificaties:

• onderhoudbaarder
• stabieler
• schaalbaarder

En uiteindelijk bespaar je daar als team enorm veel tijd mee.
Kleine keuzes in codestijl lijken onbelangrijk.
Tot je applicatie duizenden regels groot wordt