Mehrere vs. ein einziges return

[dedlfix]

Hi!

Wie gesagt, ein return ist eine unmissverständliche und direkte Anweisung. An anderer Stelle bewertete Ergebnisvariablen müssen erst angelegt und dann noch durch den Code verfolgt werden. Sie bewirken etwas indirektes.
Nachdem es nur ein return geben soll, braucht es auch höchstens eine "Ergebnisvariable".

Meinst du das "ein" jetzt als Anzahl oder als unbestimmten Artikel? Zwischen der Anzahl der möglichen returns und möglichen Ergebnisvariablen besteht keine Abhängigkeit. Beides kann unabhängig voneinander ein oder mehrmals vorhanden sein.

Wo eine Bewertung dieser Variablen stattfinden soll, verstehe ich nicht.

Als Abbruchkriterium der Schleife - dafür sind sie ja vorgesehen. Und potentiell können sie auch noch im restlichen Code ausgewertet und geändert werden. Es könnte ja Ausnahmen geben, bei denen doch nicht abgebrochen werden soll. Diese will man vielleicht der Übersichtlichkeit wegen nicht auch noch mit in eine einzige Bedingung einarbeiten. Und das sind nur die beabsichtigten Änderungen. Natürlich kann man für solche Anwendungsfälle die return-Variante nicht mehr nehmen.

Sofern das "durch den Code verfolg[en]" heißen soll, dass man nachsehen muss, ob nicht noch etwas mit ihr passiert, stimme ich zu. Bei angemessen kurzen[tm] Methoden ist das auch kein Problem. "Bewirken" tut eine Ergebnisvariable auch nix; sie wird einfach zurückgegeben. Was du damit sagen willst, mir also auch nicht 100%ig klar.

An der Stelle, an der sie mit dem Abbruchwert gefüllt wird, passiert nichts weiter. Die Wirkung des Schleifenabbruchs entfaltet sich erst an der Stelle, an der sie ausgewertet wird.

Wenn der Code nur ein einziges Mal verwendet wird, erstelle ich ungern eine Funktion, weil dadurch auch der Mehraufwand des Aufrufens und der Parameter- und Rückgabewertbehandlung hinzukommt.
Aus Performancegründen auf Subroutinen zu verzichten ist heutzutage kein gültiges Argument mehr. Das zieht maximal noch bei Code der derartig kritisch ist, dass er sowieso in Assembler geschrieben werden muss.

Akzeptiert. Bleibt der Mehraufwand beim Erstellen, der sich wenigstens mit Übersichtlichkeit rentieren sollte. Auch wenn man (bei PHP weniger üblich, aber z.B. im Visual Studio sehr gut nutzbar) mit schrittweisem Debugging einem Fehler auf der Spur ist, bewirkt so ein Abtauchen in eine Funktion eine Unterbrechung des Flusses und einen Ortswechsel im Code. Andererseits kann man den Funktionsaufruf auch überspringen. Doch dafür kann man im Geradeaus-Code einen Breakpoint bemühen, zu dem man springen kann.

Zudem verschwindet die Komplexität der gewünschten Funktionalität nicht, sie wird nur verlagert
Vom Verschwinden hat auch niemand was gesagt. Sie ist nur besser gegliedert und kann so leichter erfasst werden.

Oder auch nicht.

und ich muss nun zwei oder mehr Stellen im Auge behalten.
Wenn du was tust?

Durch das Verlagern hat man nun den übrig gebliebenen Code hier und den ausgelagerten Code in der Funktion oder in mehreren woanders. Ergibt mehrere Stellen, die zu beachten sind (statt einer großen). Auf alle Fälle muss man zum ausgelagerten Code springen (zumindest wenn man den Ablauf das erste Mal studiert), und verliert dabei vielleicht die andere Stelle aus dem Auge/Editor-Fenster.

Das ist alles sehr theoretisch betrachtet. Im konkreten Fall kann das durchaus weniger tragisch sein, als ich es hier beschreibe.

Übersichtlichkeit kann man sich durch Code-Einklappen bewahren (wenn es der Editor / die IDE bietet).
Jesses, die Code-Einklapperei! Ihr einziger Effekt ist, dass die Leute noch ermutigt werden, kilometerweise Code in eine einzige Methode zu packen. Hinfort damit! (Google e.g. "C# regions considered harmful")

<del>Unfug.</del><ins>Das sehe ich nicht so.</ins> Jedes Werkzeug kann unsachgemäß verwendet werden. Monstercode ensteht sicher nicht primär duch klappbaren Code sondern durch unüberlegtes Programmieren.

Und ich google jetzt nicht, denn ich setze #region sehr gern ein. Nicht nur, um den gerade nicht benötigten Code einklappen und mich damit schnell zwischen Codestellen hin- und herbewegen zu können, zwischen denen anderer Code liegt, sondern auch um die Methoden nach organisatorisch sinnvollen Gesichtspunkten zu bündeln.

Lo!