C++ If else oder return?

Torben schrieb:
> wie ist eure Haltung zu if else oder return in meiner Methode?
da lohnt die Frage nicht, siehe unten

> Was ist besser bezüglich Geschwindigkeit und Lesbarkeit oder gibt es
> hierfür definierte Vorgaben?
Geschwindigkeit sollte in der Frage nie eine Rolle spielen.
Lesbarkeit und Robustheit ist das Kriterum.
Sobald Du anfängst, Code doppelt zu schreiben, weil Du eine Regel 
einhälst, stimmt was mit der Regel nicht.

1

void PowerSupply::SetOutputOnOff(bool onoff)

2

{

3

    const QString SetOutput("OUT");

4

5

    if(!m_busy)

6

    { 

7

        if(onoff)

8

        {

9

            serialPortWriter->write(SetOutput.toUtf8() + " 1\r");

10

        }

11

        else

12

        {

13

            serialPortWriter->write(SetOutput.toUtf8() + " 0\r");

14

        }

15

    }

16

}

Da lohnt kein Streit für. Wobei die beiden writes für mich untereinander 
gehören:

1

void PowerSupply::SetOutputOnOff(bool onoff)

2

{

3

const QString SetOutput("OUT");

4

5

    if(!m_busy)

6

    { 

7

        if(onoff) {serialPortWriter->write(SetOutput.toUtf8() + " 1\r");}

8

        else      {serialPortWriter->write(SetOutput.toUtf8() + " 0\r");}

9

    }

10

}

So erkennt man den Unterschied sofort. Ich teile den unbedingten 
Zeilen-Fetisch nicht.

Unabhängig von dem Beispiel benutze ich lieber return. Das finde ich 
viel übersichtlicher, als eine oder sogar mehrere if-Ebenen einzubauen.

Manche argumentieren, dass dadurch der Code zu Spaghetticode würde, aber 
das finde ich gar nicht. Mit return wird die Funktion an der Stelle 
verlassen und zum Aufruf zurückgesprungen. Da ist ganz klar, was 
passiert.

A. S. schrieb:
> Sobald Du anfängst, Code doppelt zu schreiben, weil Du eine Regel
> einhälst, stimmt was mit der Regel nicht.
> [...]
Du meinst also eigentlich sowas wie

1

void PowerSupply::SetOutputOnOff(bool onoff)

2

{

3

  const QString SetOutput("OUT");

4

  const char* lineEnd = onoff ? " 1\r" : " 0\r";

5

  if(!m_busy)

6

  {

7

    serialPortWriter->write(SetOutput.toUtf8() + lineEnd);

8

  }

9

}

um das doppelte write zu vermeiden?

P. S. schrieb:
> Ich bin eher ein Anhänger davon, dass eine Funktion nur einen
> Aussprungpunkt haben sollte. Und dieser sollte am Ende der Funktion
> sein.
Da schließe ich mich voll und ganz an.
Hat gelegentlich auch verteile wenn man beim debuggen sich erstmal nur 
den Rückgabewert anschauen will und nicht gleich dutzende Breakpoints 
setzen will damit man auch jeden möglichen Aussprungpunkt zu erwischen.


P. S. schrieb:
> Die ursprüngliche Variante des Threaderstellers finde ich schon mal sehr
> suboptimal.

Dazu kommt noch das durch das "void" ein mittendrin verstecktest 
"return" fast schon "unerwartet" ist (wenn auch syntaktisch hier völlig 
richtig verwendet).
Bei so kurzen Funktionen geht das ja alles noch, aber sowie die länger 
werden übersieht man so ein verstecktes return auch mal ganz schnell.

mh schrieb:
> Du meinst also eigentlich sowas wie

Ja. Nur kostet ein zusätzliches token auch wieder temporären 
Hirnspeicher, dass ich es hier noch nicht tun würde.

Das hardgecodede Lineending ist natürlich nicht ganz portable...

Dass die Funktion so wenig Sinn macht, ist denke ich jedem klar. 
Trotzdem kann man den Teilaspekt return oder nicht ja daran ausführen.

Viele nette Anregungen sind dazugekommen. Danke.

Die Befehle kommen später alle in eine static const lookuptable und 
extra h Datei.

Die Schreibweisen von Sven B. und Rolf M. gefallen mir am besten.

>Dass die Funktion so wenig Sinn macht, ist denke ich jedem klar.
>Trotzdem kann man den Teilaspekt return oder nicht ja daran ausführen.

Wieso sollte es kein Sinn machen?

Bzgl. dem EOL:

Bekommt natürlich auch eine variable, damit bei einem anderen Netzteil 
mit anderem Protokoll auch funktioniert.

Torben schrieb:
> Wieso sollte es kein Sinn machen?

darum:

Torben schrieb:
> Die Befehle kommen später alle in eine static const lookuptable und
> extra h Datei.

Du wirst, sobald Du 5 Funktionen davon geschrieben hast, die 
Gemeinsamkeiten sehen und zusammenfassen. Sobald Du dann mehr Erfahrung 
mit Stringverarbeitung hast, bleibt quasi jeweils nur ein einzeiler 
übrig. Oder was Array-basiertes, oder ... oder...

Jedes return, das nicht am Ende der Funktion steht, entspricht einem 
goto (END:)!

Möge jeder der Befürworter hier selbst entscheiden, wie er zum goto 
steht.

;-)

no goto schrieb:
> Jedes return, das nicht am Ende der Funktion steht, entspricht einem
> goto (END:)!

genauso wie ein break. Das vermeide ich auch konsequent bei 
switch/case...

Theoretisch sollten in C++ die Exceptions und das "goto end" keine 
Probleme ergeben.

Im Gegensatz zu C übernehmen in C++ die Destruktoren der lokalen 
Variablen die Aufräumarbeiten. In C mussten wir uns noch selbst um 
free() oder close(file) kümmern. Wenn so ein "return" Probleme ergibt, 
sind die Destruktoren falsch konzipiert.

If there is nothing to do, getta outa here ;-)

Das meint ich bevorzuge ein early return immer wenn die 
Eingangsparameter
oder ein bestimmter Zustand keine Abarbeitung des Funktionsrumpfes 
zulassen.

Deshalb für mich nichts schlimmes in der TO-Variante.

Rufus Τ. F. schrieb:
> Zeig doch bitte mal ein Beispiel. Für mich hört sich das so an, als
> sollte man sich mit Grausen davon abwenden.

Bring mal deinen Ironiedetektor in die Werkstatt. Der scheint kaputt zu 
sein. ;)

A. S. schrieb:
> genauso wie ein break. Das vermeide ich auch konsequent bei
> switch/case...

Fachlich bist du ne Null Nummer, wenn du jede Funktion mit einer switch 
case_ enden läßt. :-P

Rolf M. schrieb:
> Das gilt in C++ (und diversen anderen Sprachen) auch für jede Exception,
> denn die beenden die Funktion auch vorzeitig, genau wie beim return.

Schon cool, wenn hier ein selbst ernannter Superprofi  exzeptionell und 
goto gleichwertig sieht. ???

> gleichwertig sieht

Da ist was dran.

Exceptions, goto und return ergeben das selbe Problem. Du müsst höllisch 
aufpassen. Kannst leicht bei einigen Pfaden die Aufräumarbeiten 
vergessen.

Im Beispiel ganz oben klappt es. Der Destruktor des QString kümmert sich 
um alle Aufräumarbeiten. Und der C++ Compiler ruft den Destruktor sowohl 
bei Exceptions, als auch bei return auf. Meist auch wenn ein goto den 
Scope verlässt.

Wenn die Klasse aber eine explizite close() Methode verlangt, hast du in 
allen 3 Fällen das selbe Problem.

Ich programmiere gerne in C, und finde es oft ebenfalls übersichtlicher, 
bei der Fehlerbehandlung und ähnlichem bei dem die Funktion logisch am 
"Ende" ist, mit return und goto zu arbeiten. Nichts ist schlimmer als 
unübersichtliche mehrfach Verschachtelungen, spätestens ab der 5. Ebene 
muss das übersichtlicher gemacht werden, sofern möglich. Wobei, oft 
braucht man dann nicht goto, sondern Unterfunktionen. Es muss halt 
jeweils einfach sinn machen, an der Stelle ein "Stop, alles liegen 
lassen, gehe zum Notfallexit." hinzuschreiben.

Normalerweise prüfe ich meistens Dinge wie Argumente usw. Wenn vorher 
noch keine locks gesetzt wurden und auch sonst nichts gemacht wurde, und 
irgendwas nicht gut ist, gibt das erstmal ein return. Manchmal auch ein 
Goto ans Ende wenn das in der Funktionen an anderen stellen noch gemacht 
wird.

Die Fehlerbehandlung mit goto ist relativ simpel. Man packt ans ende der 
Funktion label, die das schon gemachte in umgekehrter Richtung wieder 
aufräumen. Beispiel:

1

struct bla* create_bla(int x){

2

  if(x < 0)

3

    goto error;

4

5

  struct bla* bla = malloc(sizeof(struct bla));

6

  if(!bla)

7

    goto error;

8

9

  if(init_bla_bla(bla) == -1)

10

    goto error_after_malloc;

11

12

  if(do_bla_bla(bla, x) == -1)

13

    goto error_after_init_bla_bla;

14

15

  return bla;

16

17

error_after_init_bla_bla:

18

  cleanup_bla_bla(bla);

19

error_after_malloc:

20

  free(bla);

21

error:

22

  return 0;

23

}

Klar, in C++ hat man dafür Exceptions. Die wären wirklich praktisch, und 
es gibt auch Implementationen in C. Einziges "Problem" mit diesen ist 
halt, dass die aus einer Funktion heraus zu viel springen können, wenn 
man mal vergisst, eine zu behandeln.

Natürlich ist sowas nicht empfehlenswert:

Torben schrieb:
> if(onoff)
>     {
>         serialPortWriter->write(SetOutput.toUtf8() + " 1\r");
>         return;
>     }
>     serialPortWriter->write(SetOutput.toUtf8() + " 0\r");

Da ist ja entweder das eine, oder das andere, und dann noch weiteres, 
momentan das Funktionsende. Das Asymetrisch zu machen, und im einen Fall 
direkt zu beenden statt da normal zum ende zu gehen, macht deshalb rein 
logisch keinen Sinn. Ich würde sogar soweit gehen zu sagen, dass es 
falsch ist.

> Die Fehlerbehandlung mit goto ist relativ simpel.

Wenn das alle so machen würden, könnte das durchaus eine gute Strategie 
sein. Aber es gibt sowieso schon viel zu viele unterschiedliche 
Strategien.

Lieber ein Programm aus 10 gleichartigen mittelmässigen Komponenten 
zusammen stellen, als aus 10 genialen, aber inkompatiblen.

Ich denke das erste Return entspricht der Guard Clause. Mittendrin die 
returns sind nicht schön zumindest wenn ich die Antworten von den Usern 
zähle.

Falls jemand über den Post stolpert.

https://medium.com/@scadge/if-statements-design-guard-clauses-might-be-all-you-need-67219a1a981a

> sind nicht schön

Lisp-Programmierer vertreten da die entgegengesetzte Ansicht. Die finden 
Zuweisungen nicht schön und verlassen die Funktion an zig verschiedenen 
Stellen, sobald sie einen Return-Wert berechnet haben.

Wie ist das entstanden? Entscheiden sich Leute, die Returns nicht schon 
finden für C? Oder sind die C-Programmierer so oft auf die Schnauze 
gefallen, dass sie Returns nicht mehr als schön empfinden?

Ich hab nie lisp Programiert, aber einiges darüber gehört. Ist dort die 
Idee nicht, dass eine Funktion immer pure ist, also man nie irgend einen 
globalen Zustand ändert und deshalb nie Nebeneffekte hat? Dann kann ein 
return dort nämlich nie schaden. Und ist das dort nicht teils sogar 
notwendig, früher ein return zu haben, weil dort Funktionen oft rekursiv 
aufeinander und auf sich selbst aufbauend definiert sind, und sonst gar 
kein Ergebnis hätten oder ewig laufen würden? Das ist halt eine andere 
Art des Programmierens, die für andere Aufgaben gut geeignet sind. Das 
kann man zu einem gewissen Grad für gewisse Dinge in C Anwenden, aber 
dort kann man das halt auch falsch machen. C ist halt keine so "pure" 
Sprache wie Lisp ;)

Dirk K. schrieb:
> Und: Der Vergleich der vorzeitigen returns mit
> goto ist Bullshit.

Nö, genauso ist es: vorzeitiges return ist wie ein goto ENDE:

> Nö, genauso ist es: vorzeitiges return ist wie ein goto ENDE:

Zumindest intern erzeugt ein C++ Compiler aus den returns den selben 
Code wie DPAs goto Beispiel.

Die selbe interne Technik, nur eine andere Abstraktion darüber gelegt. 
Somit lassen sich die beiden Abstraktionen miteinander vergleichen.

Dirk K. kann nicht behaupten, der Vergleich an sich wäre Bullshit. Er 
kann höchsten behaupten: wer sich nicht seiner religiösen Überzeugung 
anschliesst, sei ein Ochse.

Nur so eine Idee schrieb:
> Dirk K. kann nicht behaupten, der Vergleich an sich wäre Bullshit. Er
> kann höchsten behaupten: wer sich nicht seiner religiösen Überzeugung
> anschliesst, sei ein Ochse.

Nein, Bullshit ist der Sprung, der hier gemacht wird:

no goto schrieb:
> jedes return, das nicht am Ende der Funktion steht, entspricht einem
> goto (END:)!
>
> Möge jeder der Befürworter hier selbst entscheiden, wie er zum goto
> steht.

Genauso gut könnte er (richtig) sagen: "Die schließende '}' einer 
while-Schleife ist wie ein goto zurück an den Anfang."

Sein zweiter Satz wäre dann genauso irreführend:
> Möge jeder der Befürworter hier selbst entscheiden, wie er zum goto
> steht.

A. S. schrieb:
> Genauso gut könnte er (richtig) sagen: "Die schließende '}' einer
> while-Schleife ist wie ein goto zurück an den Anfang."

Das ist falsch. Die '}' "beendet" mindestens auch noch einen Scope.

Die Verfechter von "nur ein return pro Funktion" mögen sich mal diesen 
völlig MISRA C++ konformen Code anschauen:

https://vcis-gitlab.f4e.europa.eu/aneto/MARTe2/blob/master/Source/Core/BareMetal/L5GAMs/MemoryMapBroker.cpp
https://vcis-gitlab.f4e.europa.eu/aneto/MARTe2/blob/master/Source/Core/BareMetal/L5GAMs/GAMDataSource.cpp

immer schön das (ret) mitgeschleift, obwohl schon mglw. ganz am Anfang 
feststeht, dass nichts weiter damit zu machen ist. Es darf ja nur ein 
return geben...

Das eigentliche Problem ist, dass jemand cyclomatic complexity zur 
ultimativen Metrik für Codequalität/-komplexität hochstilisiert hat. Ist 
es aber nicht.

DPA schrieb:
> Beispiel:
> struct bla* create_bla(int x){
>   if(x < 0)
>     goto error;
>
>   struct bla* bla = malloc(sizeof(struct bla));
>   if(!bla)
>     goto error;
>
>   if(init_bla_bla(bla) == -1)
>     goto error_after_malloc;
>
>   if(do_bla_bla(bla, x) == -1)
>     goto error_after_init_bla_bla;
>
>   return bla;
>
> error_after_init_bla_bla:
>   cleanup_bla_bla(bla);
> error_after_malloc:
>   free(bla);
> error:
>   return 0;
> }

Erinnert mich an BASIC Spaghetti Code.

So geht das in C

1

struct bla* create_bla(int x){

2

  struct bla* blabla;

3

  if(x < 0) {

4

    blabla= NULL;

5

  }

6

  else {

7

    blabla= malloc(sizeof(struct bla));

8

    if(blabla) {

9

      if(init_bla_bla(blabla) == -1) {

10

        free(blabla);

11

        blabla= NULL;

12

      }

13

      else if(do_bla_bla(blabla, x) == -1) {

14

        cleanup_bla_bla(blabla);

15

        free(blabla);

16

        blabla= NULL;

17

      }

18

      // no else: blabla is on heap

19

    }

20

    // no else: blabla is NULL;

21

  }

22

  return blabla;

23

}

Oh nein schrieb:
> immer schön das (ret) mitgeschleift, obwohl schon mglw. ganz am Anfang
> feststeht, dass nichts weiter damit zu machen ist.

if ... else ... !!!

no goto schrieb:
> So geht das in C

Sehr schön, jetzt bist du schon auf der 3. Ebenen und hast die Stellen 
wo ein Free nötig ist verdoppelt, und die wo du was auf 0 setzen musst 
verunendlich facht (0x -> 3x). Entsprechend sind auch die stellen, wo 
die vergessen werden können, vervielfacht. Aber es muss ja besser sein, 
wenn es kein böses goto drinn hat...

Beitrag "Re: C++ If else oder return?"
Na seht ihr, geht doch. ?

Und noch mehr Zuspruch gegen goto (und damit mehrfache return).
Beitrag "Re: C++ If else oder return?"

> "Die schließende '}' einer while-Schleife ist wie ein goto
> zurück an den Anfang."

Ja klar.

Angefangen hatte das mit Dijkstras Vorschlag, wir sollen nur 3 Arten von 
Sprüngen verwenden.
- Zurück an den Anfang eines Blockes.
- Einen Block überspringen
- Einen Block als Unterprogramm aufrufen

Dann entwickelten verschiedene Leute Programmiersprachen, die nur diese 
3 Arten erlauben.

Inzwischen haben wir erkannt, das dürfen wir nicht so dogmatisch sehen. 
Es gibt Situationen, in denen es besser ist, wir weichen von Dijkstras 
Vorschrift ab.

In diesen Thread passiert nun etwas vollkommen perverses.

Diejenigen, die behaupten, wir sollen Dijkstra Vorschrift nicht so 
dogmatisch befolgen, sind selbst vollkommen dogmatische 
Fundamentalisten. Wollen nur ihre eigene Abweichung von der reinen Lehre 
erlauben.

Eine Frage zu den "guard clauses":

Ich habe das Gefühl, dass hier beim Funktionsaufruf ein "Haufen" blind 
über den Zaun geschmissen wird und der andere sich über die 
Sinnhaftigkeit der Argumente kümmern darf.
Sollte man nicht vorher prüfen, ob die übergebenen Argumente/Parameter 
plausibel sind?

Tom schrieb:
> Ich habe das Gefühl, dass hier beim Funktionsaufruf ein "Haufen" blind
> über den Zaun geschmissen wird und der andere sich über die
> Sinnhaftigkeit der Argumente kümmern darf.
> Sollte man nicht vorher prüfen, ob die übergebenen Argumente/Parameter
> plausibel sind?

Das kommt ganz drauf an. Wenn bei aufrufen von verschiedenen Orten aus 
andere Randbedingungen gelten, muss man diese ausserhalb checken. Die 
Sachen, die aber immer geprüft werden können oder müssen, packt man 
besser in die Funktion, damit man später keine Überraschungen erlebt, 
und keine Fehler macht weil man es an X stellen vor dem Prüfen wieder 
checken muss. Besonders wenn man eine Aufgabe in einer Funktion 
verallgemeinert, kann sowas extrem hilfreich sein. Das ist aber manchmal 
sehr schwierig, weil man dann manchmal alle Verwendungsarten kennen 
muss, um die Funktionsargumente/API passend für alle Anwendungsfälle zu 
wählen. Sobald man wieder komplexere dinge umrechnen muss, ist die 
Abstraktion nicht mehr ideal und sollte eventuell angepasst werden.

Als ein gelungenes Beispiel von mir würde ich mal meine Funktion zum 
ändern der Cursorposition in meinem Terminal Multiplexer/Emulator 
anführen:
https://github.com/Daniel-Abrecht/libttymultiplex/blob/c519098e0b3c4b0442267d6505ea6195fc36c5e8/src/pane.c#L291
Alle Cursormanipulationen erfolgen nur über diese Funktion, die von 
ungefähr 20 Orten aus verwendet wird. (Grösstenteils von escape 
sequenzen): 
https://github.com/Daniel-Abrecht/libttymultiplex/search?p=1&q=tym_i_pane_set_cursor_position&unscoped_q=tym_i_pane_set_cursor_position
Damit werden fast alle Fehler vermieden, die bei manuellen Checks an 
jedem der Orte sonst auftreten könnten. Andererseits war es extrem 
schwer, eine gute & allgemeingültige Abstraktion zu finden und sauber zu 
implementieren. Und bei so einer Zentralen Funktion sind auch Fehler, 
besonders im Design, sehr viel schlimmer und schwerer zu beheben. Wenn 
man es hinkriegt überwiegen die Vorteile aber.

Danke für eure hilfreichen Antworten :-)

Oliver S. schrieb:
> Vincent H. schrieb:
>> "guard clauses" werden in C++20 als "contracts" kommen:
>> https://en.cppreference.com/w/cpp/language/attributes/contract
>
> Das sind aber statische Compilezeit-Checks, vor allem an Typen, während
> es hier im Thread eher um Laufzeitchecks von Wertebereichen geht.
>
> Oliver

Sicher, dass du die Seite gelesen hast? Gleich am Anfang steht:

1

Explanation

2

1) Defines a precondition, i.e., the function's expectation of its arguments and/or the state of other objects upon entry into the function. ...

In den Beispielen steht sowas

1

expects: i > 0

Das liest sich nicht sehr statisch.