GOTO's sind unschoen - oder doch nicht?

[digitali]

Bis vor kurzem war ich der festen Ueberzeugung das GOTO's in Bascom unschoen sind. Igitt, bah - so was benutzt man nicht! Und so was braucht man auch nicht!

In einem komplexeren Programm, welches ich gerade fuer ein kommerzielles Projekt schreibe, treffe ich auf eine Stelle wo diverse Ja/Nein Entscheidungen getroffen werden muessen. Und dementsprechend muss auch gesprungen werden. Kann man alles nicht so in einem Satz erklaeren, aber die GOTO's erschienen mir hier - nach laengerer Ueberlegung - wirklich als die beste Loesung. Und ich wollte nicht unbedingt Programmteile wieder in eine SUB verbannen, die dann letztendlich nur zweimal aufgerufen wird.
Ein Teil des Programmmoduls laeuft nun. Mit GOTO's. Und das sogar bestens. Bisher habe ich diesen Befehl bewusst vermieden. Einfach weil man sonst echt Gefahr laeuft in einen Spaghettiprogrammierstil abzugleiten. Und gerade bei umfangreicheren Programmen verliert man dann schnell die Uebersicht. Ich schreibe gerade nur noch Programmmodule, die dann spaeter (hoffentlich) nahtlos zusammenarbeiten...
Aber ich haette nicht gedacht, dass ich das GOTO irgendwann mal einsetzen wuerde. Und irgendwie fuehle ich mich nun auch echt unwohl dabei. ;)

Mit freundlichen Gruessen
Digitali

[radbruch]

Hallo

Letztlich wird aus dem "GoTo" ein einfacher Assemblersprung über einen Programmbereich. Eine "while", "case"- oder "if..elseif"-Konstuktion verwandelt der Kompiler auch nur in bessere Sprungtabellen. Es spricht also technisch nichts gegen die Verwendung von "GoTo".

Gruß

mic

[peterfido]

Spricht nichts gegen die Verwendung des GOTO Befehls. Sonst würde es ihn nicht geben. Ich selbst benutze ihn, wenn ich ihn für geeignet halte.

[Dnerb]

Spricht nichts gegen die Verwendung des GOTO Befehls. Sonst würde es ihn nicht geben. Ich selbst benutze ihn, wenn ich ihn für geeignet halte.

100% ACK

[chr-mt]

Letztlich wird aus dem "GoTo" ein einfacher Assemblersprung über einen Programmbereich.

So isses. Und bei Assembler redet auch keiner von Spaghetticode.
Ich komme meistens zwar ohne Gotos aus, aber es gibt eben Fälle, wo das ganz nett ist.
Heutzutage springt man ja auch nicht mehr zu Zeilennummern, sondern zu (möglichst aussagekräftigen) Labels. Von daher kann man das auch halbwegs übersichtlich halten.

Gruß
Christopher

[johns]

7.7 Das unselige goto Statement

Die Überschrift sagt im Prinzip schon vieles uber das goto-Statement aus:
Es ist eines der unseligsten Statements, die jemals in höhere Programmiersprachen Einzug gefunden haben. Bevor ich erläutere, warum man goto keinesfalls und unter keinen Umständen verwenden soll, mochte ich trotzdem zumindest seine Funktionsweise kurz beschreiben:

Im Prinzip ist goto eine unbedingte Sprunganweisung an eine Stelle irgendwo im Programm. Irgendwo im Programm bedeutet, an eine Stelle, die man zuvor durch einen Label gekennzeichnet hat.

1 // goto.c - a tiny program demonstrating the use of goto
2
3 main ( )
4 {
5 int spaghetti_counter = 0;
6
7 nirvana:
8 printf ( "I'm in nirvana...\ n" );
9 spaghetti_counter++;
10 if ( spaghetti_counter > 5)
11 goto walhalla;
12 goto nirvana;
13 walhalla:
14 printf ( " finally in walhalla \n" ) ;
15 }

Ausführen des Programms liefert den folgenden Output:

I'm in nirvana...
I'm in nirvana...
I'm in nirvana...
I'm in nirvana...
I'm in nirvana...
I'm in nirvana...
finally in walhalla

In diesem Beispielprogramm werden zwei verschiedene Labels, nirvana und walhalla definiert, die als mögliches Ziel einer Sprunganweisung dienen können. Mittels goto werden diese dann angesprungen.

Man sieht schon bei diesem winzigen Codeschnipsel, dass die Lesbarkeit des Codes eine mittlere Katastrophe darstellt. Nun stelle man sich vor, dass man es mit einem großen Programm zu tun hatte, in dem wild kreuz und quer durch das Programm gesprungen wird! Schon hier haben wir eine Schleife programmiert, die keines unserer bekannten Schleifenkonstrukte verwendet. Man muss aber zweimal hinsehen, um dies auch zu erkennen. Nun denke man daran, dass sich eine solche Schleife über mehrere Sprungstellen hintereinander im Code definiert. Kein Mensch kann dieses Konstrukt noch in vernünftiger Zeit durchschauen. Die Einfuhrung von goto in Hochsprachen fand noch zu einer Zeit statt, in der die meisten Softwareentwickler sehr viel mit Assemblersprachen zu tun hatten, bei denen unbedingte Sprunganweisungen zum täglichen Brot gehören. Intern arbeiten Computer ja nicht strukturiert, wie auch? Auch bei Anfängern in der Programmierung ist goto noch recht beliebt, da sie die Gefahr dahinter nicht erkennen. Zumeist dauert es aber dann nicht lang, bis sie ihren eigenen Code nicht mehr durchschauen, weil die Sprünge jede Struktur im Programm verschleiern.

Nicht umsonst haben jahrzehntelang viele berühmte (und auch nicht so berühmte) Softwareentwickler kein gutes Haar an diesem Statement gelassen, weil es ein Programm absolut undurchsichtig, unwartbar, nicht erweiterbar und fehleranfällig macht. Glücklicherweise hat es sich mittlerweile schon weit herumgesprochen, dass man keine goto Anweisungen verwenden soll. Warum denn auch? Es gibt kein einziges Problem, das man nicht ohne goto auch lösen konnte. Leider findet man vereinzelt noch in verschiedenen Büchern "gute Gründe" fur dieses grauenvolle Konstrukt. Aber egal, um welchen guten Grund es sich handelt, es gibt immer noch bessere Gründe, es nicht so zu machen.

In diesem Sinne schließe ich mich vollstandig der Meinung fast aller Softwareentwickler an: Ein goto hat in keinem Programm etwas verloren!!!!!

Um diese Aussage noch weiter zu untermauern: In Java ist goto ein reserved-word, aber es ist bewusst nicht implementiert. Damit hat man es gleich im Prinzip von der Sprache her nicht zugelassen und jeden Versuch zu seiner Implementierung unterbunden!

http://www.asc.tuwien.ac.at/eprog/do.../schmaranz.pdf

[Dnerb]

Gähn, niemand hat gesagt das goto der tollste Befehl auf Erden ist.

Und ob man Spaghetticode schreibt hängt nicht vom goto alleine ab.

Und gerade in C gibt es genug möglichkeiten ein Programm grauenhaft zum Lesen zu machen, auch ohne ein goto.

[johns]

goto hell

lg
johns

[fumir]

@johns
ein wirklicher experte würde nie behaupten, man solle etwas nie tun, sondern höchstens man solle es nur tun, wenn man nen guten grund dafür hat. und ein guter grund findet sich immer, wenn man nur lange genug sucht.

stures festhalten an irgendwelchen prinzipien ohne die aktuelle situation zu berücksichtigen ist nicht nur beim programmieren meistens ne schlechte idee.

dann ists auch noch ein unterschied, ob man goto in basic, pascal, c oder c++ verwendet.
basic z.b. wurde mit goto geboren. warum sollte man es dann verteufeln. in c hat mans eingebaut, um gewisse dinge nicht umständlicher als nötig formulieren zu müssen. was nützt der perfekte goto-freie code, wenn er viel länger, komplizierter und unverständlicher ist als ein kleines goto an der richtigen stelle.

[Steinigtmich]

Gotos werden doch prinzipiell verteufelt (auch ich gestehe, ich mag sie nicht), weil sie einer früheren Sprachengeneration angehören.
So entsteht ein unhübsches Mischmasch.
Ich erklär mal:
Am Anfang war die Zeilennummerbasierte programmierung. Da waren GOTOs mehr oder minder notwendig, auch wenns ja noch so eine Art Prozedur-Vorläufer gab, die mit GOSUB angesprungen und mit RETURN wieder zurückgeführt wurden.

Später kam (war das mit Modulo und Pascal?) die prozedurale Programmierung auf, mit diesem Konzept wurden die GOTOs überflüssig, wenn auch in den meissten Programmiersprachen noch implementiert, und genau hier haben wir die Situation warum es unhübsch ist, sie einzusetzen. Sie sind gegen das Konzept der Programmiersprache.

Ähnlich sieht es in Java aus, welches als objektorientierte Programmiersprache quasi noch eine "Generation weiter" ist, wenn man Methoden in einer Klasse als static deklariert. Damit verweichlicht man auch das objektorientierte Prinzip und kann diese Methoden aufrufen ohne vorher ein Objekt zu erzeugen. Schon hat man wieder prozedurale Programmierung.

Ich fasse also zusammen was ich unschön finde:
- Prozedurale Programmierung in einer objektorientierten Sprache
- Zeilennummerbasierte Programmierung in einer prozeduralen Sprache

Es ist schlicht und ergreifend unschön, weil man die Generationen der Programmiersprachen durchmischt. Funktionelle Nachteile sehe ich auch keine, halt nur stilistische.