Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

return in if-Statement

Werbeanzeige

FSA

Community-Fossil

  • »FSA« ist der Autor dieses Themas

Beiträge: 1 989

  • Private Nachricht senden

1

09.09.2018, 03:10

return in if-Statement

Hallo!

Ich habe eine allgemeine Frage, rein Interessehalber: Wie handhabt ihr das folgende Szenario (A oder B), bzw. gibt es Vor- und Nachteile abseits der Code-Lesbarkeit zwischen den beiden Versionen?

Version A:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Pseudocode
int func()
{
    if (a)
    {
        foo();

        return 1;
    }

    bar();

    return 0;
}


Version B:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// Pseudocode
int func()
{
    if (a)
    {
        foo();

        return 1;
    }
    else
    {
        bar();
    }

    return 0;
}


Auf eine mögliche Version C, mit einem weiteren return 0; im else-Statement, habe ich verzichtet.

Zitat

Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.

Garzec

Alter Hase

Beiträge: 693

Wohnort: Gießen

  • Private Nachricht senden

2

09.09.2018, 07:51

Ich würde mir das else sparen, da alles unterhalb des ifs ja bereits den else Fall darstellt.

LInsoDeTeh

Treue Seele

Beiträge: 372

Wohnort: Essen, Deutschland

Beruf: Team Lead Inhouse-Entwicklung

  • Private Nachricht senden

3

09.09.2018, 08:23

Ich sehe das wie Garzec.
Oft gibt es in Funktionen im Anfangsteil verschiedene if-Blöcke mit return-Statements direkt hintereinander, wo ungültige Argumente oder andere Ausnahmen abgehandelt werden. Je nach Fall kann das dann auch ein throw statt einem return sein.

Anschließend hast du dann den Happy Flow des Funktionscodes schön klar hinter den Fehlerprüfungen, ohne dass der sich im dreizehnten else-Block tief geschachtelt befindet. Das wäre mein Argument, auf else-Blöcke zu verzichten und wenn man diesen Stil einmal gewählt hat, sollte man ihn auch konsequent benutzen (also auch bei Weichen mit größeren Blöcken oder später in der Funktion).

D-eath

Treue Seele

Beiträge: 102

Beruf: Freelance Software Engineer

  • Private Nachricht senden

4

12.09.2018, 10:45

Die erste Variante. Ist bspw. in der Java-Welt auch Ziel von Refactorings, eine solche Schreibweise zu erreichen, da sie intuitiver und klarer ist.

hetzge

Treue Seele

Beiträge: 107

  • Private Nachricht senden

5

23.12.2018, 00:40

Es kommt ein wenig auf den Usecase an.

Ich würde hier die erwähnte Variante C wählen wo beide Zweige gleich aufgebaut sind. Wenn foo() und bar() gleichwertige Alternativen darstellen, weshalb sollte ich diese dann unterschiedlich behandeln (z.B. in Einrückung und Struktur des Codes). Man drückt mit dem else Block die Intention oft nochmal klarer aus. Generel habe ich das gefühl, dass oft Dinge weggelassen werden nur weil es möglich ist.

Zitat

Oft gibt es in Funktionen im Anfangsteil verschiedene if-Blöcke mit return-Statements direkt hintereinander, wo ungültige Argumente oder andere Ausnahmen abgehandelt werden. Je nach Fall kann das dann auch ein throw statt einem return sein.

Genau das wäre der andere Usecase. Prüfungen im Sinne von "Design by contract" würden sich durch weglassen des else eventuell mehr vom eigentlichen Code abheben.
Kunst: https://www.twitch.tv/agram :thumbsup:

Werbeanzeige

Ähnliche Themen