Du bist nicht angemeldet.

Werbeanzeige

FSA

Community-Fossil

  • »FSA« ist der Autor dieses Themas

Beiträge: 1 933

Wohnort: Hessen

  • 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 von »LetsGo«

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

Garzec

Alter Hase

Beiträge: 687

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: 370

Wohnort: Essen, Deutschland

Beruf: Softwareentwickler & Projektleiter

  • 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

Frischling

Beiträge: 93

Beruf: Projektleiter / Software-Entwickler

  • 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.

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.

Werbeanzeige