Warum denn nicht mal negativ?

Hin und wieder fragt  ein Kollege, warum er seinen Code umstellen soll. Er würde ihn gut verstehen und andere könnten sich doch auch reinfuchsen.

Das Einarbeiten in fremden Code ist aber immer wieder anstrengend und jede sinnlos vergeudete Minute summiert sich am Ende des Jahres in Tage oder gar Wochen.

Ein recht triviale Regel lautet daher, das Wichtige, die Ausnahme nach vorne stellen . Dadurch fallen diese Randbedingungen sofort ins Auge und man kann sich danach auf den eigentlichen Algorithmus konzentrieren.

Der naive Entwickler prüft gerne die regulären Bedingungen, um dann die Berechnung durchzuführen:

void test (String value) {
    if (value != null} {
        // hier ganz viel Code
    } else {
        throw new IllegalArgumentException ();
    }
}

Jenachdem wie lange der if Teil in der Methode ist, wird man durch das else am Ende etwas überrascht oder aber noch schlimmer, man übersieht es. Die einfache Lösung hier ist den boolschen Ausdruck zu negieren und die throw Anweisung nach vorne zu stellen. Vielen Entwicklern graust es davor einen boolschen Ausdruck umzuformen, obwohl es dafür schon lange feste Regeln gibt.

Durch die Throw Anweisung im if wird außerdem das else obsolet, da ja der andere Zweig mit einer Exception die Methode verlässt . Der Code wird lesbarer, da wir auf eine Einrückung verzichten können:

void test (String value) {
    if (value == null} {
        throw new IllegalArgumentException ();
    }
    // hier ganz viel Code
}

Normalerweise enthalten solche Methoden aber mehrere geschachtelt Prüfungen , die der Lesbarkeit zusätzlich schaden. Diese Verschachtelung lässt sich aber in der Regel, wie oben beschrieben beseitigen. Ein noch besserer Ansatz ergibt sich in solchen Fällen durch Delegation. Dazu aber ein andermal.