3. was ist besserer Stil !?!?

was ist besserer Stil !?!?

  • D

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

    0
  • L

    DEvent schrieb:

    @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

    0
  • ?

    weiss keiner hier ein nachschlagewerk (url oder link) in welchem programmierstil mit obiger problematik besprochen und dargestellt wird!?!?

    vielen dank.

    0

  • Entweder die 1. Variante, oder so:

    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.

    0
  • T

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

    0
  • A

    thordk schrieb:

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

    ja, sehr aussagekräftig 😃

    0
  • T

    na besser als foo2 😃

    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.

    0
  • B

    Ich habe letztens irgendwo (= vermutlich in einem Python-Buch/Internetseite/oder Forum) gelesen: "Exit as soon as possible"

    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.

    0
  • T

    Die 2. Variante kommt von Sprachen wie C. Wenn man nur einen Eintritt- und einen Austrittspunkt hat, hat man genau definierte Punkte an denen man Ressource de/allokieren kann. In C++ ist das ganze wegen Exceptions hinfällig. Jede Codezeile ist jetzt ein möglicher Austrittspunkt und damit die Objekte per RAII zu schützen. Da das Konzept also nicht paßt und die erste Variante übersichtlicher ist nehme ich diese.

    0
  • P

    Hm. Auf der einen Seite find ich persoenlich die erste Variante uebersichtlicher -wenn nix zu tun ist gleich return. Andererseits hab ich vor kurzer Zeit irgendwo eine Richtlinie a la "avoid multiple return statements" gesehen, ausgegeben von Herb Sutter. Da wuerde das so aussehen:

    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.

    0
Anmelden zum Antworten