Ein einzelnes “return”

Nach einer langen Pause, die durch Arzt- und Klinikbesuche bedingt und unvermeidbar war, kommt jetzt wieder ein neuer Beitrag. Ich fand den Titel auch ganz passend. Ich möchte heute eine Kleinigkeit zum Thema return-Statements erzählen, die hauptsächlich an Programmierneulinge gerichtet ist, aber möglicherweise auch für den ein oder anderen erfahreneren Entwickler ein nützliches Werkzeug ist.

Ich bin ein Fan, Freund und Verfechter des Single-Exit-Point Prinzips. Das bedeutet, dass es in einer Methode immer genau einen Punkt gibt, an dem die Methode verlassen wird, idealerweise an deren Ende. In meinen Augen erhöht das den Lesefluß und die Verständlichkeit von Code enorm. Ich möchte dazu ein Beispiel (in der Programmiersprache C#) bemühen, das mir letztens untergekommen ist.

In einer etwas längeren Methode sah ich am Ende folgende Zeilen:

Sieht an sich nicht so schlimm aus, doch das lässt sich schöner darstellen:

Schauen wir uns an, was wir dadurch gewonnen haben:

  1. Wir sparen uns vier Zeilen Code.
  2. Wir sparen uns eine Verschachtelungsebene.
  3. Wir sparen uns ein return.

Das sind eine Menge Ersparnisse für relativ wenig Aufwand. Ich möchte nun den Weg aufzeigen, wie man vom ersten Codeblock zum zweiten Codeblock kommt.

Zuerst fügen wir einen else Block hinzu. Das sieht zwar noch schlimmer aus, aber es hilft uns, die weiteren Schritte durchzuführen.

Dann invertieren wir die if-Bedingung (ReSharper bietet das als Shortcut an, geht aber natürlich auch von Hand).

Jetzt liest es sich schon gleich viel einfacher, da die If-Bedingung des If-Else-Konstruktes nicht negiert ist und schneller klar wird, was in welchem Teil passiert. Jetzt ändern wir das return im If-Block.

Was ist passiert? Wir haben das null durch returnValue ersetzt, da returnValue in diesem Fall null ist. Im Grunde unsinnig, aber auch das hilft uns für den nächsten Schritt.

Ähnlich dem Distributivgesetz aus der Mathematik haben wir ein gleiches Statement sowohl aus dem If- als auch aus dem Else-Block gezogen. Da die wichtigen Dinge jetzt im Else-Block stehen, invertieren wir das if erneut.

Nun ist der Else-Block leer und somit auch nicht mehr notwendig. Also streichen wir ihn einfach weg.

Jetzt müssen nur noch die zwei If-Bedingungen mit einem && verknüpft werden, um die Verschachtelungstiefe zu reduzieren, und wir haben das zweite Beispiel von oben.

Wenn man diese Vorgänge ein paar Mal wiederholt und das Konzept dahinter verinnerlicht hat, sieht man schnell, welche Return-Statements vereinfacht oder umgeschrieben werden können. Dann werdet ihr auch die Zwischenschritte nicht mehr brauchen! 🙂 Wenn ihr meine Ansicht bzgl. Single-Exit-Point Prinzip teilt, anderer Ansicht seid oder den Beitrag hilfreich fandet, lasst es mich gern in den Kommentaren wissen.

In diesem Sinne, Happy Coding!

Kommentare 2

  • Da ich auch lange Zeit ein starker Verfechter dieser Methode war, nun diese Regel aber etwas erweitert anwende my 2 cents…

    Ziel des Single-Exit-Point Prinzips ist ein verbesserter Lesefluss und möglichst wenig Breakpoints zu benötigen um beim Debugging im Fehlerfall noch genug Information über den Variablenzustand der Methode zu bekommen. Ein einzelner Exit-Point -> nur ein Breakpoint nötig.

    Ich persönlich bin mittlerweile ein starker Verfechter vorab die Eingangsparameter zu prüfen. Sind diese grob Fehlerhaft, steige ich sofort mit einem return parameterError aus der Methode aus. Es bietet sich allerdings an diesen Code Block visuell vom Logik-Code der Methode abzugrenzen.

    Dies könnte man sicherlich auch mit einem großen If-else zu einem Single-Exit-Point code zusammen führen, was meiner Meinung nach dann aber die gewonnene Differenzierung zwischen Input-Parameter Fehler oder Fehler in der Methodenlogik zerstört.

    • Ist ein guter Ansatz, den ich teilweise auch verfolge. Allerdings wird im if-block dann bei fehlerhaften Parametern ein Fehler ins Log geschrieben, im else die Logik der Methode ausgeführt.

Leave a Reply

Your email address will not be published. Required fields are marked *