Mehrere vs. ein einziges return

[Beat]

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.

Es bringt aber auch nichts, einfach so Subfunktionen zu erstellen.
Sie bringen nur dann etwas, wenn du hoffst oder erwartest, dass es sich um wiederverwendbaren Code handelt.

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.

Das ist nicht unbedingt der Fall. Sofern die Funktionen allgemein genug sind und gute Namen haben, ist die Gliederung besser. Wenn aber dies nicht der Fall ist, dann musst du immer zwischen Stellen wechseln um den Zusammenhang der Verarbeitung zu erfassen.

Spaghetticode kann man auch in Funktionen zerstückeln, es sind dann handelt zerstückelte Spaghetti.

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

Wenn du eine zu spezifische Sache in eine Funktion auslagerst.

Ü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")

Hmmm tatsächlich sind Funktionen ideal, weil ich ohne spezielle Markings das Folding im Editor erhalte.
Jedoch:  um so wichtiger wird die erste Funktionszeile.

Und das bringt mich zum return: Was der Standard return-typ ist, möchte ich gern im head einer Funktion lesen, nicht im footer.
Von daher ist die Frage, wieviele Ausgänge die Standardhose haben soll, für mich irrelevant.

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. ;-)

yup.

mfg Beat