it-swarm-eu.dev

Wann und warum sollten Sie void verwenden (anstelle von z. B. bool / int)

Ich stoße gelegentlich auf Methoden, bei denen ein Entwickler etwas zurückgibt, das für die Funktion nicht kritisch ist. Ich meine, wenn ich mir den Code anschaue, funktioniert er anscheinend genauso gut wie ein void und nach einem Moment des Nachdenkens frage ich "Warum?" Kommt Ihnen das bekannt vor?

Manchmal würde ich zustimmen, dass es meistens besser ist, so etwas wie ein bool oder int zurückzugeben, als einfach ein void zu machen. Ich bin mir jedoch im Großen und Ganzen nicht sicher, was die Vor- und Nachteile angeht.

Abhängig von der Situation kann die Rückgabe eines int den Aufrufer auf die Anzahl der von der Methode betroffenen Zeilen oder Objekte aufmerksam machen (z. B. 5 in MSSQL gespeicherte Datensätze). Wenn eine Methode wie "InsertSomething" einen Booleschen Wert zurückgibt, kann ich die Methode so gestalten, dass sie bei Erfolg true zurückgibt, andernfalls false. Der Anrufer kann wählen, ob er auf diese Informationen reagieren möchte oder nicht.

Auf der anderen Seite,

  • Darf dies zu einem weniger klaren Zweck eines Methodenaufrufs führen? Eine schlechte Codierung zwingt mich oft dazu, den Inhalt der Methode zu überprüfen. Wenn es etwas zurückgibt, sagt es Ihnen, dass die Methode von einem Typ ist, den Sie haben, um etwas mit dem zurückgegebenen Ergebnis zu tun.
  • Ein weiteres Problem wäre, wenn die Methodenimplementierung Ihnen unbekannt ist, was hat der Entwickler beschlossen, zurückzugeben, das nicht funktionskritisch ist? Natürlich können Sie es kommentieren.
  • Der Rückgabewert muss verarbeitet werden, wenn die Verarbeitung in der schließenden Klammer der Methode beendet werden könnte.
  • Was passiert unter der Haube? Hat die aufgerufene Methode false aufgrund eines ausgelösten Fehlers erhalten? Oder hat es aufgrund des ausgewerteten Ergebnisses false zurückgegeben?

Was sind deine Erfahrungen damit? Wie würden Sie darauf reagieren?

30
Independent

Im Fall eines Bool-Rückgabewerts, der den Erfolg oder Misserfolg einer Methode anzeigt, bevorzuge ich das Try- Präfix-Paradigma, das in verschiedenen .NET-Methoden verwendet wird.

Beispielsweise könnte eine void InsertRow() -Methode eine Ausnahme auslösen, wenn bereits eine Zeile mit demselben Schlüssel vorhanden ist. Die Frage ist, ob es vernünftig ist anzunehmen, dass der Anrufer sicherstellt, dass seine Zeile eindeutig ist, bevor er InsertRow aufruft. Wenn die Antwort nein ist, würde ich auch eine bool TryInsertRow() bereitstellen, die false zurückgibt, wenn die Zeile bereits vorhanden ist. In anderen Fällen, z. B. bei DB-Konnektivitätsfehlern, kann TryInsertRow dennoch eine Ausnahme auslösen, vorausgesetzt, die Aufrechterhaltung der DB-Konnektivität liegt in der Verantwortung des Anrufers.

32
Bubblewrap

IMHO, das einen "Statuscode" zurückgibt, stammt aus historischen Zeiten, bevor Ausnahmen in Sprachen mittlerer bis höherer Ebene wie C # üblich wurden. Heutzutage ist es besser, eine Ausnahme auszulösen, wenn ein unerwarteter Fehler den Erfolg Ihrer Methode verhinderte. Auf diese Weise wird sichergestellt, dass der Fehler nicht unbemerkt bleibt und der Anrufer ihn entsprechend behandeln kann. In diesen Fällen ist es für eine Methode vollkommen in Ordnung, nichts (d. H. void) anstelle eines booleschen Statusflags oder eines ganzzahligen Statuscodes zurückzugeben. (Natürlich sollte man dokumentieren, welche Ausnahmen die Methode wann auslösen kann.)

Wenn es sich andererseits um eine Funktion im engeren Sinne handelt, d. H. Eine Berechnung basierend auf Eingabeparametern durchführt und erwartet wird, dass das Ergebnis dieser Berechnung zurückgegeben wird, ist der Rückgabetyp offensichtlich.

Es gibt eine Grauzone zwischen den beiden, wenn eine möglicherweise beschließt, einige "zusätzliche" Informationen von der Methode zurückzugeben, wenn dies für ihre Aufrufer als nützlich erachtet wird. Wie Ihr Beispiel über die Anzahl der betroffenen Zeilen in einer Einfügung. Für eine Methode zum Einfügen eines Elements in eine assoziative Auflistung kann es hilfreich sein, den vorherigen Wert zurückzugeben, der diesem Schlüssel zugeordnet ist, falls vorhanden. Solche Verwendungen können durch sorgfältige Analyse der (bekannten und erwarteten) Verwendungsszenarien einer API identifiziert werden.

28
Péter Török

Peters Antwort deckt die Ausnahmen gut ab. Andere Überlegungen betreffen hier Command-Query Separation

Das CQS-Prinzip besagt, dass eine Methode entweder ein Befehl oder eine Abfrage sein sollte und nicht beides. Befehle sollten niemals einen Wert zurückgeben, nur den Status ändern, und Abfragen sollten nur den Status zurückgeben und nicht ändern. Dies hält die Semantik sehr klar und macht Code lesbarer und wartbarer.

Es gibt einige Fälle, in denen ein Verstoß gegen das CQS-Prinzip eine gute Idee ist. Diese betreffen normalerweise die Leistung oder die Gewindesicherheit.

14
Andy Lowry

Was auch immer der Weg ist, du wirst damit gehen. Haben Sie dort keine Rückgabewerte für die zukünftige Verwendung (z. B. lassen Sie Funktionen immer true zurückgeben). Dies ist eine schreckliche Verschwendung von Aufwand und macht das Lesen des Codes nicht klarer. Wenn Sie einen Rückgabewert haben, sollten Sie ihn immer verwenden. Um ihn verwenden zu können, sollten Sie mindestens zwei mögliche Rückgabewerte haben.

3
refro

Ich habe viele leere Funktionen geschrieben. Aber da ich mich mit der gesamten Methode der Verkettung von Rissen befasst habe, habe ich angefangen, dies zurückzugeben, anstatt es nichtig zu machen - könnte genauso gut jemanden die Rückgabe nutzen lassen, weil man nicht mit Leere hocken kann. Und wenn sie nichts damit anfangen wollen, können sie es einfach ignorieren.

1
Wyatt Barnett