long foo(long pSomeLong)
{
  if( Bedingung( pSomeLong ) )
    return;

  DoBerechnung( pSomeLong );
  DoThis();
  DoThat(); 
  MaybeThisToo();
  return CalcResult( pSomeLong );
}

oder 2.

long foo(long pSomeLong)
{
  if(!Bedingung( pSomeLong ) )
  {

   DoBerechnung( pSomeLong );
   DoThis();
   DoThat(); 
   MaybeThisToo();
  }
  else
    return 0;
  return CalcResult( pSomeLong );
}

ich denke 1. ist besser.
was denkt ihr?
gruss

ganz subjektiv: Ich kann Ersteres besser/schneller verstehen und würde das deswegen vorziehen.

Gruß,

Simon2.

return 0

... gemeint
ich ziehe auch erstere variante vor. aber bei mir am arbeitsplatz gibt es ein paar herren, die das fruehe ermitteln von ausstiegskriterien und dann ein unmittelbares return nicht so schoen finden.
ich glaubte mich irgendwo zu erinnern, dass ich sowas mal gelesen habe dass variante 1. besser ist.
Wer einen hinweis hierauf (auf obige problematik des stils) weiss, bitte link oder url schicken.

vielen dank.
gruss.

Aber ich fürchte, das hier könnte zu einem Galubenskrieg ausarten.

In der Tat, wobei ich denke die Notwendigkeit für Methode 2 ist dank RAII nicht mehr gegeben. Notorische goto-Meider hatten vorher quasi keine andere Wahl (mal abgesehen von der Aufspaltung in Mikrofunktionen)

int ret = OK;
FILE* f = fopen(...);
if (f) {
    Struk* s = read_and_create(f);
    if (s) {
        ....
        free(s); // <-- (2)
    } else
        ret = FEHLER;
    fclose(f); // <-- (1)
} else
    ret = FEHLER;

return ret;

vs.

fstream f(...);
if (!f) return FEHLER;

auto_ptr< Struk > s( new Struk );
if (!s->read(f)) return FEHLER;

return OK;
// <-- (1) und (2), falls jemals erzeugt

sobald man irgendwo, an irgendeiner stelle, ein return sieht, dann kann man sich 100% sicher sein, dass die aktuelle methode mit dem wert verlassen wird, der an der stelle steht.

sonst man sich erstmal durch einen wust an if/else oder womöglich noch diverse gotos quälen muss, bis man feststellt, was der ganze krempel soll.

man sollte als faustformel weiterhin im kopf behalten: mehr als drei tabs einrückungstiefe sind meist schon zuviel spaghettierung und ab fünf tabs sollte man den code einstampfen

@LordJaxom: Beim ersten Codebeispiel wird die Datei gar nicht geschlossen, wenn read_and_create() einen ungueltigen Pointer zurueckliefert.

Hast recht, ich arbeite schon zu lange nicht mehr mit C. Da könnte man dann einer Returnvariablen in den else-Zweigen Fehlercodes zuweisen und das Return als letzte Anweisung plazieren. Aber das Beispiel ändere ich jetzt nicht mehr ab, ich denke der Sinn ist klar

EDIT: Doch noch geändert

vielen dank.

long foo(long pSomeLong)
{
    return Bedingung(pSomeLong) ? 0 : foo2(pSomeLong);
}

long foo2(long pSomeLong) 
{
    // ggf. das assert weglassen, kommt drauf an was der Code eigentlich macht, und ob
    // "!Bedingung(pSomeLong)" eine "precondition" für den folgenden Code ist
    assert(!Bedingung(pSomeLong));

    DoBerechnung(pSomeLong);
    DoThis();
    DoThat();
    MaybeThisToo();
    return CalcResult(pSomeLong);
}

EDIT: BTW: diese prefixes ("p") sind ganz ekelig, und "p" verwendet man normalerweise für Zeiger, und nicht für Parameter.

würd dann aber nen aussagekräftigeren bezeichner wählen. fooImpl oder so

ja, sehr aussagekräftig

long foo(long someLong)
{
  if(Bedingung(someLong))
   return fooImpl(someLong);
  return 0;
}

long fooImpl(long someLong)
{
  ...
}

abgesehen vom bezeichner hat diese methode den vorteil, dass man eine funktion schreiben kann, die garantiert mit einem "korrekten" wert aufgerufen wird. macht das ganze übersichtlicher.

Alleine vom Codeverständnis ist es mir angenehmer eine Funktion (oder einen Block) dann zu verlassen, wenn es möglich/nötig ist.

Vom Laufzeitverhalten dürften sich beide Varianten nicht viel tun (wenn ich mal so an meine "Assembler-Zeit" zurückdenke). Um ein CMP und ein JE, JNE (x86) etc. kommt man ja ohnehin nicht herum.

long foo(long pSomeLong)
{
  long ret = 0;
  if(!Bedingung( pSomeLong ) )
  {
   DoBerechnung( pSomeLong );
   DoThis();
   DoThat();
   MaybeThisToo();
   ret = CalcResult( pSomeLong );
  }

  return ret;
}

/edit: hab mich halbwegs vertan, er hat diese Regel zwar mal aufgestellt, sie aber wohl wieder verworfen: http://www.gotw.ca/gotw/002.htm Punkt 5.