early return?

Welche Variante bevorzugt ihr?
a)

Foo* foo = getFoo();
if ( foo == NULL )
{
  return;
}
some(foo);
bar(foo->getBars());
...

b)

Foo* foo = getFoo();
if ( foo != NULL )
{
  some(foo);
  bar(foo->getBars());
  ...
}

_matze

Ich habe nichts gegen frühzeitiges Aussteigen aus einer Funktion, solange dies gut gekennzeichnet ist. Das erspart einem unnötig tiefe Verschachtelungsebenen.

Blue-Tiger

Erstere: erst ein paar Sanity-checks, die evtl. auch gleich zurueckspringen, und dann der weitere Code. Sonst wirds unuebersichtlich und es erhoert nur unnoetig die Einrueckungsebene.

DrGreenthumb

immer a)

hustbaer

Eigentlich auch immer a).

In dem speziellen Beispiel allerdings noch lieber eine Variante mit einem Wrapper um getFoo() der brav eine Exception wirft wenn das Objekt nicht verfügbar ist. Vorausgesetzt es entspricht einem Fehler wenn getFoo() "NULL" zurückliefert.

wenn die gesamte methode problemlos auf den bildschirm passt (das bedeutet für mich: maximal 50 zeilen), dann sind early returns ok. ansonsten sollte eine methode genau einen ausstiegspunkt haben, und zwar ganz am ende. und early returns auch bitte immer anständig klammern und am besten mit einem kommentar kennzeichnen. sonst findet man sich irgendwann überhaupt nicht mehr zurecht.

_matze

unleashed schrieb:

wenn die gesamte methode problemlos auf den bildschirm passt (das bedeutet für mich: maximal 50 zeilen), dann sind early returns ok.

Aber gerade bei großen Funktionen ist sind tiefe Verschachtelungen doch eher nachteilig. Da habe ich lieber ein, zwei bedingte returns am Funktionsanfang. Ich weiß ja, dass ich sie immer dort finfen kann.

unleashed schrieb:

und early returns auch bitte immer anständig klammern und am besten mit einem kommentar kennzeichnen. sonst findet man sich irgendwann überhaupt nicht mehr zurecht.

Da muss ich dir zustimmen! Das Schlimmste sind solche Geschichten:

void myFunc() {
  foo();
  bar();
  foo(bar()+foobar());
  if(bX) return;  //schön mittendrin versteckt, ohne Einrückung und Klammern, kein Kommentar => ein Wunder, wenn man das auf Anhieb sieht...
  bar(foo(bar()));
  rgne();
  //...
}

hustbaer schrieb:

In dem speziellen Beispiel allerdings noch lieber eine Variante mit einem Wrapper um getFoo() der brav eine Exception wirft wenn das Objekt nicht verfügbar ist.

das ist ja mal wieder typisch Java/C#-programmierer

unleashed schrieb:

ansonsten sollte eine methode genau einen ausstiegspunkt haben, und zwar ganz am ende.

und am freitag müssen funktionen immer einen rückgabewert haben, ne? bringt sonst alles unglück.

topic: ich bevorzuge methode a, wenn ich sonst einen grösseren block in klammern setzen müsste. gegen methode b spricht ausserdem der negierte vergleich.

tntnet

unleashed schrieb:

wenn die gesamte methode problemlos auf den bildschirm passt (das bedeutet für mich: maximal 50 zeilen), dann sind early returns ok. ansonsten sollte eine methode genau einen ausstiegspunkt haben, und zwar ganz am ende. und early returns auch bitte immer anständig klammern und am besten mit einem kommentar kennzeichnen. sonst findet man sich irgendwann überhaupt nicht mehr zurecht.

Wenn die gesamte Methode problemlos auf den Bildschirm passt (das bedeutet für mich: maximal 50 zeilen), dann sind early returns ok.
Ansonsten sollte die Methode geteilt werden, daß sie problemlos auf den Bildschirm passt .

frenki

Ausschliesslich a)

Demnächst kommt noch jemand daher und verlangt, dass jede Funktion auch nur am Ende eine Exception werfen darf.

frenki schrieb:

...dass jede Funktion auch nur am Ende eine Exception werfen darf.

werfen muss.

rapso

die moeglichkeit die wahrscheinlicher true ist.

Helium

Bin ich an C++ gebunden oder ist das eine allgemeine Frage? Bei einer allgemeinen Frage wähle ich c) die monadische Variante.

Shade Of Mine

Wenn man mal weiß warum es die Idee einer Single-Entry-Single-Exit Funktion gibt, dann sollte man wissen wann sie sinn macht und wann nicht. In C++ macht es zB nie sinn (genauso in java oder c#). in C dagegen schon.

Mr. N

Helium schrieb:

Bin ich an C++ gebunden oder ist das eine allgemeine Frage? Bei einer allgemeinen Frage wähle ich c) die monadische Variante.

Wäre gut, wenn du auch sagen würdest, was das ist.

Shade Of Mine schrieb:

Wenn man mal weiß warum es die Idee einer Single-Entry-Single-Exit Funktion gibt, dann sollte man wissen wann sie sinn macht und wann nicht. In C++ macht es zB nie sinn (genauso in java oder c#). in C dagegen schon.

Warum? Also gerade in C kann man durch geschicktes initialisieren, überprüfen und vorzeitiges freigeben und beenden ja eine Menge an Code-Komplexität in Verbindung mit dynamischem Speicher vermeiden.

Tyrdal

Worauf Shade hinaus wollte, ist wohl, daß in Exceptionhaltigem Code jede Menge versteckte Austrittspunkte enthalten sind. Single-Exit wird da eher schwierig, egal wo du dein return hinschreibst.

Shade Of Mine schrieb:

Wenn man mal weiß warum es die Idee einer Single-Entry-Single-Exit Funktion gibt, dann sollte man wissen wann sie sinn macht und wann nicht.

dann erklär doch bitte mal, wann sie sinn macht.

Shade Of Mine

wenn man code hat der immer beim exit ausgeführt werden muss, zB cleanup code. in c++ und java hat man das problem aber nicht da man für solche fälle destruktoren bzw. finally hat...

Shade Of Mine schrieb:

wenn man code hat der immer beim exit ausgeführt werden muss, zB cleanup code.

das ist selbstverständlich. aber das 'return' muss nicht die letze anweisung im code (als höchste zeilennummer) sein, wie manche behaupten.