Warum wird "sonst" selten nach "wenn x dann zurückkehrt" verwendet?

https://stackoverflow.com/questions/3261849

16-09-2020
|

Frage

Diese Methode:

boolean containsSmiley(String s) {
    if (s == null) {
        return false;
    }
    else {
        return s.contains(":)");
    }
}

kann äquivalent geschrieben werden:

boolean containsSmiley(String s) {
    if (s == null) {
        return false;
    }

    return s.contains(":)");
}

Nach meiner Erfahrung wird die zweite Form häufiger gesehen, insbesondere bei komplexeren Methoden (bei denen es mehrere solcher Austrittspunkte geben kann), und das gleiche gilt sowohl für "Werfen" als auch für "Zurückgeben".Die erste Form macht die bedingte Struktur des Codes jedoch wohl expliziter.Gibt es Gründe, das eine dem anderen vorzuziehen?

(Zusammenhang: Sollte eine Funktion nur eine return-Anweisung haben?)

Lösung

In meiner Erfahrung hängt es vom Code ab.Wenn ich gegen etwas 'bewachen', mache ich:

generasacodicetagpre.

Der Punkt ist klar: Wenn diese Anweisung falsch ist, möchte ich nicht, dass die Funktion fortgesetzt wird.

Andererseits gibt es einige Funktionen mit mehreren Optionen, und in diesem Fall würde ich es so schreiben:

generasacodicetagpre.

Obwohl es geschrieben werden könnte als:

generasacodicetagpre.

Es kommt wirklich darauf auf, auf welchen Weg deutlich zeigt, was der Code tut (nicht unbedingt, welches Bit von Code kürzest ist oder die geringste Einrückung hat).

Andere Tipps

Der else in diesem Fall wäre dies redundant und würde unnötige zusätzliche Einrückungen für den Hauptcode der Funktion erzeugen.

Dies ist ein Muster namens Wächterklausel .Die Idee ist, alle Überprüfungsvorgänge, um verschachtelte Bedingungen zu reduzieren, um die Lesbarkeit zu erhöhen.

aus dem link:

generasacodicetagpre.

Mit der Guard-Klausel können Sie dieses Ergebnis sehen:

generasacodicetagpre.

Du wirst das überall sehen:

if (condition) {
    return var;
}
// by nature, when execution reaches this point, condition can only be false,
// therefore, the else is unnecessary
return other_var;

Meistens ist das Hinzufügen einer else Klausel in diesem Fall nicht nur unnötig, sondern wird oft auch optimiert weg durch den Compiler.

Überlegen Sie, wie der Computer über diesen Code denkt (in Bezug auf Maschinencode, hier zu Demonstrationszwecken in Pseudocode vereinfacht):

0x00: test [condition]
0x01: if result of test was not true, goto [0x04]
0x02: push [var] onto stack
0x03: goto [0x05]
0x04: push [other_var] onto stack
0x05: return from subroutine

Der Code (auch dies ist ein Pseudocode und keine Assembly) würde sich für einen genauso verhalten if/then/else bedingter.

Es wird von vielen Leuten als schlechte und / oder verwirrende Praxis angesehen, mehrere mögliche Austrittspunkte für eine Funktion zu haben, da ein Programmierer an jeden möglichen Pfad durch seinen Code denken muss.Eine andere Praxis ist die folgende:

return (condition) ? var : other_var;

Dies vereinfacht den Code und erstellt keine neuen Austrittspunkte.

Ich schreibe es lieber so:

generasacodicetagpre.

Wie jede "Diskussion" über Codierungsstile gibt es keine richtige Antwort.Ich lieber diese Überlegungen anwenden:

funktioniert der Code in allen Situationen erwartet.(Prinzip der am wenigsten Überraschung)

Kann der nächste Entwickler (ich oder jemand anderes) verstehen, was es tut und warum.

Wie zerbrechlich ist der Code in Bezug auf Veränderung.

ist einfach, da es sein muss und nicht mehr.D. H.nein oder unter technisch.

Sobald ich froh bin, dass ich das oben genannte zufrieden bin, der Rest ist im Allgemeinen nur fällt in die Linie.

Ich würde die erste Option bevorzugen, da es mehr menschenlesbar ist.

Als Analogie vergleichen Sie die nächsten 2 Sätze: "Wenn heute regnet, nehmen Sie einen Regenschirm, sonst nehmen Sie Sonnenbrillen."Und "wenn heute regnet, nehmen Sie einen Regenschirm, nehmen Sie Sonnenbrillen".Der erste Satz entspricht dem ersten Codeblock aus der Frage, dem zweiten - bis zur zweiten.Der erste ist viel klarer und lesbarer, nicht wahr?

Jemand anderes hat das wahrscheinlich schon bemerkt, aber ich würde es empfehlen, Nullwerte im Allgemeinen zu verwenden, wo Saiten erwartet werden.Wenn Sie wirklich eine Überprüfung wünschen, um zu verhindern, dass jemand Null-Werte passiert, können Sie Asserts (bei dev Time) oder Gerätestests verwenden (Bereitstellen):

generasacodicetagpre.

Ich habe auf eine allgemeine Faustregel umgeschaltet: nie.Je.PASS NULL-Werte, es sei denn, dass keine externen API-Anrufe ausdrücklich fragt.Zweitens: Wenn ein externes Verfahren Nullwerte zurückgibt, ersetzen Sie ihn durch einen vernünftigen Nicht-Null-Wert (z. B. eine leere Zeichenfolge) oder fügen Sie einen ordentlichen Scheck hinzu.Ich wächst satt von repetitiven Grippeticeticetagcode-Überprüfungen.

Das ist aber ein bisschen Offftopic.Ich mag es, kurze Bedingungen auf die Ober- und Wachschlüsse einzusetzen, um Els zu entfernen, wenn der Programmfluss diktiert, dass es nie dorthin kommt.

Es ist religiöses Argument und am Ende des Tages spielt es keine Rolle.Ich würde sogar argumentieren, dass die erste Form unter Umständen lesender ist.Wenn Sie in einem if-elseif-elseif-else großen Code-Code haben, ist es einfacher, auf den ersten Blick zu sehen, wie die Standardrückgabe ist.

generasacodicetagpre.

Occams Rasiermesser ist das Prinzip, dass "Entitäten nicht über die Notwendigkeit mehr multipliziert werden dürfen."

Der if die Anweisung überprüft / erzwingt Ihren Vertrag / die Erwartung, keine Nullwerte zu erhalten.Aus diesem Grund würde ich es vorziehen, es vom Rest der Funktion getrennt zu sehen, da es nichts mit der eigentlichen Logik dessen zu tun hat, was Sie erreichen möchten (obwohl dies der Fall ist) sehr einfach).

In den meisten Fällen bevorzuge ich jedoch, dass Code in seiner Absicht so explizit wie möglich ist.Wenn es etwas gibt, das Sie an Ihrer Funktion umstrukturieren können, um es für andere lesbarer zu machen, tun Sie es.Als professioneller Programmierer sollte Ihr Ziel wirklich darin bestehen, für diejenigen zu programmieren, die Ihren Code nach Ihnen pflegen müssen (einschließlich Sie selbst 2 Jahre später...).Alles, was Sie tun können, um ihnen zu helfen, ist es wert, getan zu werden.

Der else ist überflüssig.Auch einige IDEs (Eclipse) und Analysetools (möglicherweise FindBugs) kennzeichnen dies möglicherweise als Warnung oder Fehler, sodass Programmierer es in diesem Fall wahrscheinlich entfernen werden.

Ursache es schöner.Sie wissen, dass Sie auch '{' '}' ein paar Nächtsniveaus erstellen können, aber niemand macht es wirklich für nur das Heck davon.

Während eines anderen zu haben ist richtig, und es ist nichts falsch daran, dass in Bezug auf Logik und Laufbarkeit nichts falsch ist, ich miete gerne den anfänglichen WTF-Moment, wenn die Funktion keine Return-Anweisung außerhalb des IF / else-Umfangs hat.

Das erste Formular ist einfach weniger ausführlich - wenn Sie einen Wert zurückgeben, überlassen Sie automatisch den Umfang der Funktion, in der Sie sich befinden, und kehren zum Anrufer zurück, so dass jeder Code danach nur ausgeführt wird, wenn die IF-Anweisung nicht istbewerten auf true und anschließend alles zurückgeben.

Ich würde zur Lesbarkeit argumentieren.Wenn Sie Scannen von Screens of Code, die versuchen, herauszufinden, was der Code tut, ist es eine visuelle Aufforderung zum Entwickler.

... aber es ist nicht wirklich notwendig, weil wir alle unseren Code so gut kommentieren, richtig?:)

Meiner Meinung nach macht der zweite mehr Sinn.Es dient als "Standardaktion", wie ein Schalter.Wenn es nicht mit einem der anderen Ausgangspunkte übereinstimmt, dann tun Sie das.Sie brauchen nicht wirklich ein anderes dort.Ich würde sagen, wenn die gesamte Funktion nur dann ist, wenn und elseIf, dann würde ein anderer dort sinnvoll sein, weil es ein riesiger Zustand ist.Wenn es mehrere Bedingungen und andere Funktionen gibt, die darin ausgeführt werden, wird eine Standardrückgabe am Ende verwendet.

Wie Sie sehen, haben verschiedene Personen unterschiedliche Meinungen zur Lesbarkeit.Manche Menschen denken, dass weniger Codezeilen den Code neigen, um den Code lesbarer zu machen.Andere denken, dass die Symmetrie der zweiten Form es lesbarer macht.

Mein Nehmen ist, dass wahrscheinlich beide Ansichten richtig sind ... für die Menschen, die sie halten.Und die Folgerung ist, dass Sie keinen Code schreiben können, den jeder optimal lesbar findet.Der beste Rat ist es, zu folgen, was Ihr Mandat-Codierungsstandard zu tun hat (wenn dies etwas dabei sagt) und nutzen Sie im Allgemeinen Ihren gesunden Menschenverstand.(Wenn Sie mit einem störenden Nitwit belastet sind, der darauf besteht, dass sich auf seine Weise "richtig" ist ... gehen Sie einfach mit dem Fluss.)

Because there is an optional (switched off by default) warning in eclipse if else is used in such situation ;).

Well, some of the reason is just convention, but there is one advantage to the form above...

It's typical when coding a return statement, to make the last statement your default return value. This primarily aids during refactoring - else clauses tend to get wrapped up in other structures, or might accidentally be moved deeper into the tree.

I would prefer one exit point over multiple from maintenance perspective. Final result can be modified(or decorated) at one exit point rather than n exit points.

The second form if simpler/shorter. This doesn't always mean clearer. I suggest you do what you find clearest.. Personally I would write.

static boolean containsSmiley(String s) { 
    return s != null && s.contains(":)"); 
}

Because it's the same as writing one of the following which brings the evidence about the intention of the programmer:

boolean containsSmiley(String s) {
    if (s == null)   // The curly braces are not even necessary as the if contains only one instruction.
        return false;

    return s.contains(":)");
}

Or even this:

boolean constainsSMiley(String s) {
    return string.IsNullOrEmpty(s) ? false : s.Contains(":)");
}

These two forms are:

More elegant;
Easier to read;
Leaner and swifter for the reading programmer.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow