Label vs Methode
Hallo,
im Rahmen meiner Ausbildung beschäftige ich mich derzeit intensiv mit Methoden, Konstruktoren, Klassenvererbung etc.
Nun kenne ich aus meiner Assemblerzeit den Umgang mit Labels und habe jetzt bei einem Projekt festgestellt, daß die Nutzung von Labels statt Methoden oftmals die Sache wesentlich vereinfacht.
Wie denkt ihr darüber?
Für meinen Dozenten habe eine kleine Abhandlung darüber geschrieben (mit Beispielen). Wer möchte, kann sich das ja mal reinziehen.
Hallo!
Goto gibt es zwar in C#, wird aber nicht viel benutzt, da es den Code unleserlich, unstrukturierter und auch fehleranfälliger macht.
Dexter
Programmierer sind Maschinen die Koffein in Quellcode umsetzen.
Hallo Cyron,
deine Ausarbeitung mag für einen Assembler-Programmier (ich weiß wie man mit Assembler programmiert) logisch klingen, ist aber - so leid es mir tut - völliger Blödsinn. Ich kann es nicht anderes sagen. Zumal die Begründung über die Lebensdauer von Variablen auf Grund von Instanzvariablen schon mal auf wackligen Füßen steht. Und dann "Unterprogramme", die nur von einer Stelle aufgerufen werden? Warum schreibst du dann nicht den Code des "Unterprogramms" direkt an diese Stelle? Sorry, das ist durch Assembler induzierte Geschmacksverwirrung.
Nur zur Sicherheit: Ich meine das nicht böse, weil ich auch verstehen kann, wie du dazu gekommen bist. Ich wollte nur unmissverständlich sein.
herbivore
Hi Cyron!
ich hab mir deine Ausarbeitung auch mal zu gemüte geführt und muss herbivore eigentlich vollkommen zustimmen.
Die Begründung für die Nutzung von Labels, das man damit sich Variable am Leben erhält für den Unterroutinenaufruf. Naja, das lässt sich ja auch Problemlos mit Member-Variablen erledigen. Dann hast du das Problem mit der Lebensdauer auch nicht mehr.
Ich schlage also auch mal in den allgemeinen Tenor mit ein und sage, das Labels und gotos in Hochsprachen eigentlich nichts mehr verloren haben. Ich kann mich nur an eine Situation erinnern, als ich sie in einem C-Treiber genutzt hab, um ein finally damit zu realisieren.
Auch als ehemaliger Assembler-Programmierer finde ich goto's nicht wirklich heiss. Um if und switch nach zu bauen ists ok, aber sobald unterroutinen ins Spiel gekommen sind, hab ich allein wegen der Wiederverwendung, lieber richtige unterfunktionsaufrufe und den Stack benutzt.
Gruß Jake
Die genannten Gründe lassen sich eigentlich auf einen Nenner bringen. Dir fehlt die Erfahrung mit objektorientierter oder auch nur strukturierter Programmierung. Daraus Empfehlungen zur Nutzung einer objektorientierten Sprache abzuleiten halte ich für sehr gewagt.
Viele der Probleme die du auflistest empfinde ich als völlig konstruiert.
Was muss man sich für Gedanken wegen ref, out und params? Entweder man braucht es oder nicht.
Was ist so toll daran, dass die Variablen erhalten bleiben? Wenn ich ne Variable in einer Methode brauche, wird sie übergeben und fertig. Ich sehe das Problem absolut nicht.
Und mal ganz ehrlich. Wenn eine Subroutine nur von einer Stelle aufgerufen wird, gibt es nur zwei Gründe das nicht direkt da rein zu schreiben: Wartbarkeit und Wiederverwendbarkeit. Ein goto trägt dazu nichts bei.
e.f.q.
Aus Falschem folgt Beliebiges
@Cyron
Warum willst du den Thread hier löschen lassen?
Das einzige was man dir Vorwerfen könnte, wenn man das wollte ist die fehlende Erfahrung; Wie Traumzauberbaum schon geschrieben hat. Und sowas ist nicht peinlich. Es gibt niemanden der etwas anfängt und sofort alles rockt. Das geht einfach nicht.
Du hast dir halt gedanken gemacht wie man Dinge, die aus deiner Sicht Probleme darstellen, lösen kann, und hast dafür auf das Wissen und die Erfahrung die du schon hattest zurück gegriffen. Das spricht alles für dich. Das einzige Problem bei der Sache ist, das Assembler Programmierung und OOP ungefähr soviel miteinander gemeinsam haben wie Tauchen und 'n Weltraumspazierganzg. Man bracht für beides 'ne Sauerstoffflasche (bzw. 'nen PC oder µC), aber das war's dann auch schon wieder.
Von dem her bin ich dafür das der Thread erhalten bleibt. Vielleicht hilft er ja irgendwann jemandem wenn er auf die gleiche Idee kommt.
Jake
Hallo Cyron,
ich schließe mich Jakes Argumentation an. Das muss dir nicht peinlich sein. Und da wir ohnehin nur in wenigen Ausnahmefällen (kommerzielle Werbung, rechtswidrige Inhalte, ...) Threads löschen, bleibt der Thread bestehen.
herbivore
Ich wollte auch ehrlich keinen beleidigen.
Man muss nicht alles können, ich bin kein Freund von Low-Level Problemen, ich entwerfe lieber Algorithmen als Operationen zu zählen.
Und wenn der Threadersteller damit klarkommt und sich das für ihn bewährt hat, soll er doch weiter so Programmieren.
Das Einzige was mir an der Sache eben nicht gefällt ist, dass es eben so als Richtlinie formuliert wurde. Man sollte soetwas nur formulieren, wenn man sich auf dem Gebiet auch sicher bewegen kann.
Die grundlegende Richtline in allen höheren Programmiersprachen ist eben, dass gotos zu meiden sind. Denn sie erschweren im Allgemeinen das Debuggen, die Lesbarkeit, die Erweiterbarkeit und die Wiederverwendbarkeit von Code.
Und man sollte diese Richtlinie erst verlassen, wenn man weiß worauf man sich einlässt. Sprich es muss dazu keine Anleitungen für Anfänger geben, weil Anfänger das nicht machen sollten. (Als Assembler Programmierer weiß man ja ziemlich gut wie man mit gotos umgehen muss)
Ich bin auch schon oft leichtfertig an kleine Programme rangegangen mit dem Gedanken im Hinterkopf, dass ich den Code nie wieder sehen muss. Und dann ist das Programm eben nur ne Sammlung von 2-6 größeren Funktionen, die alle nicht sonderlich durchschaubar sind. Und viel zu schnell kommt sowas wie ein Bummerang zurück und man wirft für eine kleine Änderung den halben Code weg.
e.f.q.
Aus Falschem folgt Beliebiges
Wieso Richtlinie? Ich hab nur meine Gedanken aufgeschrieben. Zieh mal deine Hassbrille ab.
Sonst hast du nichts zur Verteidigung deiner Abhandlung zu sagen?
Du formulierst das alles in der Art: "Wann kann ich Labels Methoden vorziehen"
Inwiefern ist das keine Richtlinie?
Wirklich peinlich wird das ganze, weil du einerseits auf deiner Meinung beharrst und dich aber nicht zu den Problemen die hier vorgetragen wurden äußerst.
e.f.q.
Aus Falschem folgt Beliebiges
Hi!
Ich verfolge den Thread schon von Anfang an.
Nun möchte ich dazu ersteinmal meine Meinung loswerden. Wenn man von der Assembler-Programmierung herkommt, kann ich die Punkte, warum gotos Methoden vorzuziehen sind, nachvollziehen. Sobald man aber die Assembler-Programmierung verlässt, geraten diese (erstmal schneinbaren) Vorteile ad absurdum, da labels und gotos eine Linearität des Programms voraussetzen, welche es gar nicht mehr gibt. Ein modernes Windows-Programm reagiert ereignissgesteuert mit dafür vorgesehenen Methoden. Klassen kann man schreiben und anwenden. Der Anwender der Klasse will von dem Inhalt derer nicht viel erfahren, umgedreht ist es der Klasse egal, wer sie anwendet. Labels sind an dieser Stelle nicht nur unangebracht sondern äußerst unpraktisch.
Daher sollte man das Rad nicht neu erfinden wollen und in der objektorientierten Programmierung Methoden einsetzen. Letztenendes läuft Cyrons Vorschlag mit Labels auch nur eine händische Methodenimplementierung hinaus (Ein Block an Anweisungen wird gestartet, wenn dieser abgearbeitet ist, wird zurückgesprungen)
@Cyron: In so einem Forum muss man sich vor Augen halten, dass man schriftlich mit den anderen kommuniziert. Daher kommt ein und derselbe Beitrag bei 10 Personen in 10 verschiedenen Sichtweisen an. Generell ist dir niemand böse oder macht sich lustig, das möchte ich dir versichern. Für ein Forum wie dieses ist es durchaus eine sinnvolle Sache dieses Thema zu diskutieren. So hast du deine Argumente gebracht und wir unsere Gegenargumente 🙂 Peinlich muss es dir aus diesem Grund erst Recht nicht sein! Im Prinzip ist es eine echt gute Sache, dass du dir solche Gedanken machst und zeigt, dass du dich in das Thema reinkniest 👍 Allerdings ist die Gegenmeinung praktisch bewährt und etabliert. 😉
der Marcel
:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]
Hallo Cyron,
ich kann da auch weit und breit keine Hassbrille erkennen. Der Beitrag von Traumzauberbaum ist sachlich formuliert und zeigt im Gegenteil viel Verständnis und nur einen einzigen Kritikpunkt. Und selbst bei dem hat sich jetzt geklärt, wie du es gemeint hast.
Hallo zusammen,
bitte beschränkt euch - wenn ihr das nicht ohnehin schon getan habt - auf eine sachliche Diskussion ohne Spitzen. Wenn ein unproduktiver Schlagabtausch entsteht, werde ich der Empfehlung von Robert G folgen.
herbivore
Original von Traumzauberbaum
Wirklich peinlich wird das ganze, weil du einerseits auf deiner Meinung beharrst und dich aber nicht zu den Problemen die hier vorgetragen wurden äußerst.
Ich beharre nicht auf meiner Meinung. Wenn es so wäre, hätte ich meine Gedanken hier nicht zur Diskussion gestellt. 🙂
Natürlich habe ich eingesehen daß meine Ansicht über Labels eine Schnapsidee war. Darum möchte ich mich hiermit für den ganzen Quatsch entschuldigen.
Schwamm drüber?
P.S.: Ich möchte mich bei allen für die rege Teilnahme bedanken. 🙂