nicht angemeldet
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". Wo eine Bewertung dieser Variablen stattfinden soll, verstehe ich nicht.
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.
Und grundsätzlich gilt natürlich: Das Problem bei meterlangen Methoden ist, dass sie meterlang sind. Dieses Problem lässt sich weder durch ein einziges noch durch mehrere returns beheben, sondern nur durch ein Aufteilen des Codes auf mehrere Methoden.
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.
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.
und ich muss nun zwei oder mehr Stellen im Auge behalten.
Wenn du was tust?
Ü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")
Das Einklappen von ganzen Methoden ist was anderes, dagegen gibt es nix zu sagen. Logisch, es hilft ja nur, wenn der Code auf mehrere Methoden verteilt ist. ;-)
Aber das ist jetzt nur eine theoretische Betrachtung, und ich argumentiere vor allem auch deshalb so, um mir das Gefühl zu geben, in dieser Diskussion Recht zu behalten :-) Im konkreten Anwendungsfall könnte ich durchaus anders entscheiden, je nachdem, was ich dann als sinnvoller empfinde.
Jämmerlicher Opportunist! ;-)
Grüße
Bernhard
MudGuard
Der Martin