return mitten in einer Methode?

[EDIT]Abgeteilt von 2 if anweisungen zusammen[/EDIT]

Hi!

An deiner Stelle wäre es vielleicht überlegenswert, return-Anweisungen in deine if-Blöcke einzubauen, um die Verschachtelung aufzulösen. So findest du deinen Logikfehler evtl. schneller. 🙂

der Marcel

Das ist genau der falsche Weg.

Niemals Return einfach so irgendwo in einer Routine einbauen.

Das fällt Dir immer irgendwann auf die Füsse.
Der Programmfluss sollte nicht durch soetwas "durcheinenader" gebracht werden,
auch wenn man mit GC und finally die meisten der Probleme in den Griff bekommt.

Glaube mir, wenn Du in 4 Wochen/3 Monaten wieder durch den gleichen Code
debuggen musst, wirst Du das zu schätzen lernen.

Hi FZelle!

Da kann ich dir nicht zustimmen.
ich gebe dir mal ein Beispiel, bei dem ich dafür tatsächlich Sinn sehe:

private void DoSomething()
{
     if(entscheidung1) 
     {
           //Anweisungsblock
          return;
     }
     if(entscheidung2)
     {
           //2. und letzter Anweisungsblock
     }
}

Wenn meine Methode wie hier viele if-Blöcke enthält, nach denen das Methodenende kommt und entscheidung1 false sein muss, damit entscheidung2 überhaupt noch geprüft wird, sehe ich hier mehr Übersichtlichkeit, die Methode vorzeitig abzubrechen als über else if weiter zu verschachteln. Das habe ich zu schätzen gelernt, nachdem ich lange später solche Konstrukte wieder verstehen wollte 🙂
Natürlich darf man die returns nicht ziellos setzen, sondern sich bewußt sein, was man macht und ob man damit nicht irgendetwas wegwirft, was später benötigt wird.
Wenn man keinen konkreten Nutzen daraus zieht, stimme ich dir aber zu, sollte man es lassen und die Methode "natürlich" auslaufen lassen.

der Marcel

Dazu gibts doch else if. Nur das es nicht mehr elsif zusammengeschrieben wird, aber von der Logik ists doch genau das gleiche. Da wird nicht weiterverschachtelt.

Was ist auch wenn du nun nach dem ganzen Vergleichen Code ausführen willst? Des Return springt dir aus die gesamte Funktion.

Das hat Marcel ja gesagt, daß das mit den return nur dann sinnvoll ist (bzw, er hält es nur in den fällen für sinnvoll), wenn eben sonst nichts weiter gemacht werden soll. Sprich also, wenn von der ersten entscheidung abhängt, ob der ganze rest überhaupt ausgeführt werden soll.

Macht der Optimierer in diesem Fall dann später nicht eh das gleiche draus ? (ernste frage - ich weiß es nicht)

Hi!

@talla: mit Verschachteln meinte ich auch die logische Verschachtelung, welche auch durch else if aufgestellt wird. Ich kann nur sagen, dass mir das Durchdenken der Logik leichter fällt, wenn an der richtigen Stelle solche Ausstiegspunkte gesetzt sind, um das ganze (logisch) zu Entzerren. Angenommen in dem else führe ich ersteinmal Anweisungen aus und dann die if-Abfrage, so bekomme ich dann auch eine weitere Einrückungsebene, welche ich mir so ersparen kann.
Und einfach so ein bißchen was einzufügen, wenn man die Arbeit der Methode nicht richtig versteht, fällt einem meistens auch ohne returns schon auf die Füße 😉 Da gebe ich dir Recht, wenn man das dann nicht nicht bedenkt, sucht man nach den lustigsten Fehlern 🙂

der Marcel

Am besten du springst mittels goto ans Ende der Funktion und machst da dein Return..... kleiner Scherz.

Ich denke auch, dass die "Nur-ein-Return"-Regel nicht mehr aktuell ist. Die stammt aus Vor-OO-Zeiten ohne Polymorphie und Exception-Handling, langen Funktionen mit vielen Ifs und Switches. Bei einem solchen Spaghetti-Code macht eine solche Regel Sinn.

Grunsätzlich folgen wir Menschen in unserer Denkweise dieser Regel auch nicht. Wenn etwas zuende ist, interessiert uns der Quatsch, der eh nicht mehr relevant ist, uns auch nicht mehr. Wir machen dann auch ein gedankliches "return".

Man kann ohne weiteres Fälle konstruieren, wo die "1-Return-Regel" zu objektiv schlechter lesbarerem Code führt....

Hallo FZelle,

Glaube mir, wenn Du in 4 Wochen/3 Monaten wieder durch den gleichen Code debuggen musst, wirst Du das zu schätzen lernen.

also ich programmiere seit ca. 20 Jahren so. Mir ist das noch nie auf die Füße gefallen. Ganz im Gegenteil! Ohne return ist ein Programm oft wesentlich schwerer zu verstehen.

Ich habe gerade neulich wieder ein Programm von einem Kollegen gewartet, dass wegen fehlender returns, drei Schachtelungseben mehr als nötig hatte. Nötig waren zwei; er hatte fünf. Wenn ich nach seinem Stil weitergearbeitet hätte, hätte die nötige Programmänderung zu zwei weiteren Einrückungsebenen geführt und wäre mit dann sieben Einrückungsebenen schon sehr unübersichtlich geworden. Mit return waren es am Ende nur zwei Einrückungsebenen.

Ich sage es mal so: return macht den Kopf frei. Oder anderes gesagt entlastet den Kopf vom else-Stack. Wenn ich ein return statt einem else verwende, kann ich diesen Ausführungspfad gedanklich abhaken. Ansonsten merken ich erst bei den vielen geschweiften Klammern am Methodenende, dass auf diesem Pfad keine weiteren Aktionen folgen.

Jetzt kannst du sagen, dass ich ja einzelne Einrückungsebenen in extra Methoden auslagern könnte. Sicher, kann man das, aber dann verlagert man die Komplexität in diese Aufteilung, die man im Kopf haben muss. Statt eines else-Stacks, muss man dann einen Aufrufstack führen.

Um also einen Gegenpart zu setzen: Leute, wenn ihr les- und wartbare Programme wollt, dann verwendet wo immer möglich return.

herbivore

PS: @sevenson: Diese Fälle muss man nicht konstruieren. Ich habe ja ein praktisches Beispiel beschrieben. Das bewusste Programm befand sich in realem Einsatz.

Mein Post war auch net so gedacht das ich nur immer ein return antrebe 🙂 Hatte des überlesen dass er ja als Bedingung gesagt hatte das kein Code mehr kommt 😁

Des Gute ist ja sogar, wenn du jetzt nur solche Vergleiche hast, kein Code mehr danach, das der Compiler dich ja warnt, bzw. nen Fehler wirft das nicht alle möglichen Fälle was zurückgeben, falls du irgendwo nen return vergessen hast.

Ich erinner mich noch mit Schauder an nen C++ Programm wo ich bei ner Funktion mit Rückgabeparameter nichts zurückgegeben hab und es kam noch net mal ne Warnung! Da macht das Debuggen Spaß 🙂

Ich finde sowieso, dass solche Regeln dem Problem nicht gerecht werden. Es geht hier um les- und wartbaren Code. Da spielt in ersten Linie die Komplexiät (z.B. cyclomatische) eine Rolle. Wenn man ein gründliches Refactoring macht, fallen in der Regel Methoden von max. 20 Zeilen länge heraus. Da spielt es keine Rolle mehr, wie viele Returns man hat.

Die Return-Regel versucht also so ein Problem auf formalem Wege zu lösen, führt aber dabei keineswegs zu einer Komplexitätsreduktion sondern nur zu einer anderen Code-Struktur. Strukturveränderung macht aber nur Sinn, wenn sie mit Komplexitätsreduktion einhergeht.

Auf gut deutsch: Die Regel verwechselt Ursache mit Wirkung.

Hallo svenson,

Wenn man ein gründliches Refactoring macht, fallen in der Regel Methoden von max. 20 Zeilen länge heraus.

diese Voraussetzung würde ich aus zwei Gründen nicht gelten lassen. Erstmal ganz einfach deshalb, weil es viele reale Programme gibt, die nicht/nie gründlich refakturiert werden (können), aber trotzdem weiter gewartet werden (müssen). Zweitens, weil es ablauforientierte Probleme/Problemstellungen gibt, in einen auch eine Refaktorierung sinnvollerweise nicht zu so kurzen Methoden führt, weil die die Ablaufstuktur auseinander reissen würdem.

Die Return-Regel versucht also so ein Problem auf formalem Wege zu lösen, führt aber dabei keineswegs zu einer Komplexitätsreduktion sondern nur zu einer anderen Code-Struktur. Strukturveränderung macht aber nur Sinn, wenn sie mit Komplexitätsreduktion einhergeht.

Es kommt ja darauf an, wie man Komplexität misst. Ich bin durchaus der Meinung, dass man mit return die Komplexität verminden kann. Genauso gut könntest du sagen, dass Refactoring nur die Code-Struktur ändert und damit nicht die Komplexität ändert. Natürlich haben Strukturänderungen Einfluss auf die Komplexität.

Auf gut deutsch: Die Regel verwechselt Ursache mit Wirkung.

Kann ich nicht nachvollziehen.

herbivore

Hallo!

Natürlich habe ich noch keine 20jährige Programmiererfahrung, aber vielleicht ist die Sichtweise eines Lernenenden auch interessant 🙂 : Mit vorzeitigen Ausstiegen wird für mich die eindeutig Komplexität reduziert und Verständlichkeit erhöht, weil man, wie herbivore schon sagte, den Teil gedanklich abhaken kann. Fange ich aber an, alles formal zu verschachteln, bekomme ich immer mehr logische Stufen hinhein, welche man alle im Hinterkopf behalten muss. Wenn es wirklich arg wird, verstehe ich den Code nur zu einem Zeitpunkt richtig: Dann, wenn ich ihn schreibe (dann ists aber richtig arg 🙂 ). Für eine Fehlersuche benötige ich so auch gehörig länger, weil man dann jede Bedingung in jeder Stufe durchdenken muss.
Dazu fällt mir die Logik-Vorlesung ein: Nicht umsonst fallen dort 80% der Studenten beim ersten Anlauf durch... 😁

der Marcel

@Svenson:
Auch ich bin schon über 20 Jahre dabei, und ich muss leider feststellen, das nicht
alle deiner/unserer Berufskollegen damit zurechtkommen.

Ich komme ursprünglich aus der technischen Entwicklung, wo meist eher Dipl.Ings als Informatiker anzutreffen sind, und die sind leider meist
hoffnungslos mit soetwas überfordert.
Auch die ganzen BWL'ler, die "nebenbei" SW machen können leider ziemlich
häufig mit soetwas aufwarten, und die SW ist dann ein Graus.

Und ich muss Dir rechtgeben, das Refaktoring einen deutlichen zuwachs an
Lesbarkeit bringt, wenn man Sie dann durchführen kann.

Du solltest immer bedenken, das die meisten hier keine Profies mit so viel
Erfahrung und Weitblick sind, und deshalb mit diesen Regeln besser fahren,
und dadurch schon weniger Fehler machen.

Aber wenn jemand das so falsch versteht, wie du beschrieben hast, ist das kein
zwingender Grund dagegen.

Ich kenne auch einen Haufen Entwickler die mit C# einen grausamen Spagetticode schreiben,
genauso wie ich Embedded-C Entwickler kenne, die Sauber und strukturiert arbeiten.

Diese ganzen Vorgehensweisen, und Pattern sind ja nicht als Knebel für die guten und
kreativen SW-Entwickler entstanden, sondern damit alle etwas besser/schneller/sauberer
voran kommen 😉
Und damit "wir" nicht so häufig mit soetwas konfrontiert werden.

Hallo FZelle,

Ich komme ursprünglich aus der technischen Entwicklung, wo meist eher Dipl.Ings als Informatiker anzutreffen sind, und die sind leider meist hoffnungslos mit soetwas überfordert.

mir ist nicht recht klar, wie einen returns überfordern können. Wie gesagt, eher das Weglassen von returns kann überfordern.

Du solltest immer bedenken, das die meisten hier keine Profies mit so viel Erfahrung und Weitblick sind, und deshalb mit diesen Regeln besser fahren, und dadurch schon weniger Fehler machen.

Ich bin der Meinung, dass sowohl Anfänger als auch Profies mit der Regel, dann ein return zu verwenden, wenn der Ausführungspfad abgeschlossen ist, besser fahren. Der Beitrag von Marcel zeigt ja sehr schön, dass auch für einen Anfänger die Vorteile offensichtlich sind. Insbesondere sein Argument, dass man ohne returns den Code nur beim Schreiben versteht, finde ich sehr schwerwiegend. Code wird weit öfter gelesen als geschrieben. Es ist also gerade wichtig, dass er leicht gelesen werden kann.

Aber wenn jemand das so falsch versteht, wie du beschrieben hast, ist das kein zwingender Grund dagegen.

Wer hat was, wann, wo falsch verstanden?

Ich kenne auch einen Haufen Entwickler die mit C# einen grausamen Spagetticode schreiben,

Falls sich das auf return bezieht. return ist in meinen Augen ein strukturiertes Konstrukt.

herbivore

Es ging darum, das einige SW-Entwickler überfordert sind, wenn mehr als
ein "Ausgang" aus einer Routine vorhanden ist.

Und man kann da genauso drüber diskutieren, wie über zuviele Kommentare.
Es ist fruchtlos, da wir beide ziemlich unterschiedliche Erfahrungen mit
anderen Entwicklern gemacht haben.

Hallo allerseits,

Also da muss ich herbivore zustimmen.
Es gibt viele Beispiele, bei denen ein Weglassen eines returns nur zur Unübersichtlichkeit führen würde. Wenn man in Angst hat, dass man den Code in 3 Monaten nicht mehr versteht sollte man eben ein paar kommentare einfügen - wozu sie ja schließlich auch da sind 😉.

Ich programmiere nun seit etwa 2 jahre und ich habe schon nach nem Halben Jahr (damals noch Ansi C) mehrere Rücksprünge verwendet, und es hat mich nie verwirrt.

Und mal ehrlich, wenn man durch mehrere Rücksprünge überfordert ist - was ich mir nicht vorstellen kann - sollte man sich vlt überlegen ob man für den beruf/ das Hobby geeignet ist.

wo meist eher Dipl.Ings als Informatiker anzutreffen sind, und die sind leider meist
hoffnungslos mit soetwas überfordert.

Ich finde zwar auch, dass es viele wirklich unqualifizierte Studenten gibt, die im 3ten oder 4 Semester Wirtschaftsinformatik immer noch probleme mit vielen Dingen der Programmierung haben, aber ich glaube kaum, dass ein Diplom Ing. damit überfordert ist. Wenn ja möchte ich gerne wissen, wie er sein Studium beenden konnte.

Mit freundlichen Grüßen

Dann wirst Du im "richtigen" Leben ziemlich häufig enttäuscht werden.

Nur weil jemand auf einem Gebiet etwas auf dem Kasten hat, muss das nicht
überall sein.

Ich kenne ziemlich viele Ings, die mit solchen sachen überfordert sind.
Hauptsächlich die Mech/Elektro/Nachrichten Ings, haben bis vor garnicht allzulanger
Zeit im Studium kein/wenig Informatik gemacht.

Und die meisten Leute, die derzeit im Arbeitsmarkt unterwegs sind, haben
Ihr Studium auch schon ein paar Jahre hinter sich, aber die machen
eben das Groh der SW-Entwickler aus, nicht die "paar" Informatiker,
oder "Freaks" 😉

Es gibt sicherlich Vorteile für die return's, aber auch Nachteile.

Ich verwende es gerne bei solchen Methoden:

public int Methode(string prüfe)
{
  switch(prüfe)
  {
     case "A": return 0;
     case "B": return 2;
     case "Z": return 2385;
     default: return -1;
  }
}

Auch ein guter Vorteil ist es, wenn man erkennt, dass weitere Schleifenvorgänge Fehler ergeben würden, mit den Variablensatz den ich zur Verfügung hab. Dann flüchte ich auch gerne mit return weg - spart man sich n haufn Überprüfungsaufwand.

Nicht so gern verwende ich es bei logischen Funktionen bzw. Methoden die auf andere aufbauen (Vererbung).

So, das ist mein Senf 🙂

Es ist wirklich so, dass viele SW-Entwickler heute aus artverwandten Bereichen z.B. E-Technik oder Maschinenbau kommen, und da fehlt dann vielleicht etwas der theoretische Hintergrund.

Ich hab mit Dipl.Ings. die Erfahrung gemacht, dass es meist als einziges Kriterium darauf ankommt, dass das Programm "funktioniert". Wenn man später, wenn ein Fehler aufgetreten ist, aber 2 Monate suchen muss um in dem Spaghetti-Code den Fehler aufspüren zu können, dann wird das oft mit Sprüchen wie "das ist immer so in der SW-Entwicklung" abgetan.

Also ich teile aus eigener Erfahrung die Bemerkungen hier zu einigen Dipl.Ings. Es gibt allerdings auch positive Exemplare 🙂

Hi!

ich bin angehender Ingenieur im Maschinenbau 🙂

und da fehlt dann vielleicht etwas der theoretische Hintergrund.

Das Problem bei Studiengängen ist, dass sich wirklich jeder mit Abitur dafür einschreiben und losstudieren kann ohne das irgendwie nach der Eignung gefragt wird. Nach der Eignung für das klassische Denken der Mechanik (und ansatzweise auch der Elektrotechnik) wird im Grundstudium darüber entschieden, ob man weiterkommt. Informatik? Ja, die wird hochgehoben "Schaut, ohne geht es nimmer!" Aber das, was dann im Grundstudium geboten wird, ist zwiespältiger: Zwei Semester "Informatik": Das erste davon ist der Umgang mit CAD-Programmen, also nicht wirklich richtige Informatik. (Jedoch das Nonplusultra für Maschinenbau-Ingenieure!!!) Für den, der schon privat den PC nutzt, ist das aber überhaupt kein Problem ohne dass man irgendetwas von der richtigen Informatik verstanden haben muss. Das zweite Semester, bei dem sich die Geister dann aber scheiden: Programmiereinstieg mit Delphi. Aber nicht, dass einen dort theoretische Grundlagen zur Programmierung vermittelt werden: Stattdessen lernt man die Bedienung der Borland-IDE, erstellt im Designer ein paar Textboxen und Buttons, doppelklickt auf die Buttons um Methoden für Events zu schreiben (wobei es natürlich keine Rolle spielt, warum man es gerade an dieser stelle in den Quellcode schreibt...) und schreibt Code, um auf der Form Linien und Kreise zu zeichnen. Datentypen werden einem erklärt, weil man sie zwangsweise dabei braucht. Und warum ist das so? Weil sich jeder für einen Studiengang einschreiben kann. Somit hat der Lehrende immer das Problem, dass Leute in der Vorlesung sitzen, welche sich nur langweilen (bzw. schon zur zweiten Vorlesungen gar nicht erscheinen) und die, denen man es versuchen kann beizubringen, aber es in der Zeit eh nicht schafft, weil sie vorher kaum etwas mit Computern zu tun hatten. Aber natürlich soll die Informatik nicht das Rauswurf-Kriterium für Maschinenbau-Studenten sein...obwohl sie immer mehr an Bedeutung für den klassischen Maschinenbau erlangt. Dadurch sind die Informatik-Kenntisse auch heutiger Diplomanten sehr unterschiedlich. Selbstverständlich kann man bei einer Diplom-Arbeit auch regen Gebrauch davon machen, wenn man die Programmierung für die Aufgabe benötigt. Werkzeugmaschinen mit Windows-Betriebssystem? FEM-Software ohne interdisziplinäre Zusammenarbeit gar nicht möglich? Virtuelle Bauteil-Datenbanken wie geolus Shape? Das ist Realität...

Zum anderen ist die Informatik noch eine relativ junge Wissenschaft. Somit befinden sich sicherlich noch viele im Beruf, welche den reinen Informatik-Abschluß, wie es ihn heute gibt, gar nicht haben (können). Die Tendenz dürfte langfristig aber fallend sein. Jedoch kann man auch heute nicht mit Sicherheit sagen, wo es einen im Berufsleben hinverschlägt. Dass Nicht-Informatiker über Umwege zum Software-Entwickler werden, lässt sich nicht ausschließen, wobei aber auch die umgekehrte Richtung denkbar ist.

In Zukunft wird es wohl immer stärker auf das Miteinander der Disziplinen ankommen. Die Mechatronik ist der erste Schritt in eine richtige Richtung...

der Marcel 🙂

Hallo der Marcel !

Also ich hoffe, Du hast meinen letzten Beitrag nicht als Vorwurf verstanden. Mir ging es mehr darum zu beschreiben, wie manchmal verschiedene Sichtweisen aufeinandertreffen können. Während es für eher praktisch orientierte Leute in der SW-Entwicklung (wie z.B. Dipl.Ings) halt oft darum geht, dass estwas "funktioniert" sind die eher theoretisch Veranlagteren oft an einer möglichst "sauberen" Lösung interessiert, die die klassischen OOD-Anforderungen möglichst umfassend erfüllt (Stichwort Pflegbarkeit, Erweiterbarkeit etc.).

Das Problem ist dass es oft schwer ist, jemandem der ja auch mal einige Jahre akademische Laufbahn hinter sich hat, aber der nie etwas von diesen Kriterien gehört hat - selbige zu vermitteln.

Was Du im Hinblick auf die Uni beschreibst kann ich aber auch als Informatiker nachvollziehen. Selbst im Informatik-Studium wird m.E. nach zu wenig spezialisiert. Es wird viel Wert gelegt auf Gedankenmodelle, die jetzt rein dem Software-Entwickler meist überhaupt nichts nutzen (Bsp. Turing-Maschinen o.Ä.). So kommt es auch garnicht selten vor, dass Diplom-Informatiker, die frisch von der Uni kommen, erstmal das Programmieren lernen müssen.

Ich denke das Hauptproblem in all diesen technischen Studiengängen ist, dass sie viel zu breit gefächert sind. Es wird immer versucht, Grundkenntnisse auf allen möglichen Teilbereichen zu vermitteln, so dass man am Ende "alles schonmal gehört hat" - aber meist von keinem Teil tiefergehende Fachkenntnisse besitzt.

Mehr Spezialisierungsmöglichkeiten wären hier meiner Meinung nach der richtige Schritt, denn in der Praxis kommt es später weniger darauf an, dass man bei allem mitreden kann, sondern dass man in seinem Arbeitsbereich stark ist. Ich habe z.B. an der Uni die Hardware-Entwicklungs Vorlesungen gehasst, weil mich dieser Bereich kaum interessiert, und bis heute hat noch niemand von mir verlangt, mal aus der SW-Abteilung kurz in die Produktion zu gehen und irgend einen Chip zusammen zu bauen.

Hi Lynix!

Nein, das hatte nicht so verstanden (ein bißchen Geläster gibts doch überall g). Schließlich arbeitet man immer mit 5% Ungenauigkeit 😁
Ferner finde ich eben, dass man sich in den Fachbereichen über die Thematik des Zusammenarbeitens viel mehr Gedanken machen muss. Letztenendes besteht ja ein Großteil der entstehenden Technik aus Komponenten aller Fachrichtungen. Dabei kommt meiner Meinung nach die Informatik unbegründet noch viel zu kurz. Das Beispiel Werkzeugmaschine mit Windows-Betriebssystem verdeutlicht die eigentliche Notwendigkeit doch sehr deutlich. Heute ist es eben auch sehr von Vorteil ordentliche Kenntnisse in der Informatik zu haben.
Mit dem, was ich sage, kann ich jetzt nur für die TU Dresden sprechen: Als Studiengänge gibt es die Informatik, Wirtschaftsinformatik, Medieninformatik und die Informationssystemtechnik (Informatik + Elektrotechnik, um, wie du sagst, in die Hardwareentwicklung gehen zu können). Dazu kommen im Hauptstudium die einzelnen Vertiefungsrichtungen. Im Maschinenbau hat sich das ganze auf jeden Fall so entwickelt, wie du es für richtig hälst: Wir haben zig Spezialisierungsrichtungen (wobei man nach dem Studium durchaus noch was anderes machen kann). Zudem gibt es eine enge Zusammenarbeit mit der Industrie (Mitarbeiteraustausch, Projekte, Gastdozenten) und jeder Student muss ein halbes Jahr Industriepraktikum absolvieren, wobei er in der Regel mit einer konkreten Aufgabenstellung für diese Zeit betraut wird. Möchte zwar nicht sagen, dass die Absolventen dadurch schon perfekt sind, aber sie finden meistens einen guten Einstieg in die Unternehmen.

😁 Vorsicht, der Thread entwickelt sich weit ab vom eigentlichen Thema 😁

der Marcel

Ich sehe nicht, wo wir uns von dem Grund dieses Threads entfernen.

Es ging ja primär um das wieso und warum, und gerade bei solchen
grundsätzlichen Sachen ist dieser Hintergrund wichtig.

Nicht jeder in unserer Branche hat das glück nur mit "echten" Entwicklern zu arbeiten.

Aus den Erfahrungen anderer entstehen ja dann Vorgehensweisen und Pattern
für den weiteren Weg, bzw. das Verständnis für die Vorgehensweisen anderer.

Hallo FZelle,

der "Beweis", dass "unechte" Enwickler mit einem return am Ende besser fahren, steht m.E. aber noch aus. Im Gegenteil halte ich das Ein-return-Dogma für einen Tick der "echten" Entwickler. Ich bin ja auch für strukturierte Programmierung und die Vermeidung von unstrukturierten Sprüngen (goto). Aber das Ein-return-Dogma scheint mir ein Überbleibsel aus "pädagogischen" Sprachen wie (Wirth-)Pascal.

herbivore

Hi!

In einem Buch zu C# von Microsoft Press habe ich in einem Beispiel ebenfalls ein vorzeitiges return gefunden. 😉 Finde, damit fährt man wirklich nicht übel.

der Marcel

Kann schon sein, das bei mir solche sachen aus Pascal,Modula,Ocam, Oberon und co
übergeblieben sind, aber ich würde es nicht als dogma bezeichnen.

Wie gesagt, ich habe die Erfahrung gemacht, das viele Leute so besser arbeiten.

Ich bin da inzwischen recht schmerzfrei, ich amüsiere mich nur noch über Goto's und CO,
aber wenn mich jemand zu meiner Ansicht fragt, dann sage ich das auch so.