Ein Wort zu Goto Befehlen

GOTOs, sind simple Sprunganweisungen. Man setzt einfach eine Marke im Text und kann dann jederzeit mit einem GOTO dorthin springen. Und genau da liegt das Problem. Gerade viele unerfahrene Programmierer schreiben einfach mal wild drauf los und gucken was hinten rauskommt. Oft muss man dann von einer Stelle zur anderen springen und weil das ja so leicht ist fügt man dann ein GOTO ein. Kann ja nichts passieren, ich weiß ja was ich da mache und was mein Code machen soll.

 

Nur, bleibt es dann meist nicht bei diesem GOTO, sondern es kommt irgendwo noch ein Zweites hinzu. Und ein Drittes. Und ehe man es sich versieht, hat man Spaghetticode produziert. Spaghetticode deshalb, weil wenn ich einen Teller Spaghettis habe und nehm mir davon ein Ende eines Spaghettis, kann ich nicht wirklich sagen an welcher Stelle denn mein anderes Ende liegt. Da hätten wir dann auch schon das erste Problem mit GOTOs. Der Quellcode wird undurchschaubar und schlecht leserlich. Ja sicher, unser Programmierer weiß ja was er macht, der zuckt die Schultern und sagt, er kennt sich in seinem Code aus. Schon mal daran gedacht, dass durch deinen grottigen Quellcode sich auch mal jemand anders wühlen muss? Auf der Suche nach einem sporadischem Problem, welches du durch intensiven Einsatz von GOTOS programmiert hast und das erst 2 Jahre nachdem du die Anlage programmiert hast aufgetreten ist?

 

GOTO Programmierer machen sich aber selbst schon während einem Projekt die Arbeit schwer. Wie oft sieht man diese Spezies mal schnell ein GOTO einflicken und plötzlich tritt unerwartetes Verhalten auf und es kommen Aussagen wie: "Hui, das muss man ja dann auch noch bedenken!"

Die Aussage erstaunt mich immer wieder, als wäre es so schwer von vornherein zu überlegen was man macht. Meistens kommt das von jemandem, dem man mal eine Programmiersprache beigebracht hat, aber nicht wie man sie effizient verwendet, oder wie man ordentlich an Programmierung herangeht. Als Konter hört man da gerne, daß ja auf ner Baustelle das alles schnell gehen muss und Zeitdruck und so weiter... und jaja, jede menge faule Ausreden um an seinem mieserablen Programmierstiel festhalten zu können.

 

Dabei ist das ganze eigentlich recht einfach. Habe ich von vornherein ein durchdachtes und gut konstruiertes Programm, welches so geschrieben wurde, daß auch Erweiterungen problemlos möglich sind, brauch ich GOTOs eigentlich überhaupt nie in Erwägung zu ziehen. "Jaaaaaa, aber..." schallt es mir da entgegen. "GOTOs können unter Umständen sogar die Lesbarkeit von Code erhöhen." Und die Beispiele dazu bleibt einem der Behaupter meistens schuldig. Den Code den ich durch GOTOs vereinfachen kann, der ist keine 100 Zeilen lang und lesbarer wird es dadurch noch lange nicht.

 

"Aber wenn ich kein GOTO benutze, muss ich ganz viele verschachtelte Schleifen benutzten und...!" heults mir in den Ohren.

"Gib Ruhe! Wenn du verworrene Schleifen verwenden musst ist vielleicht mal an der Zeit sich zu überlegen ob vielleicht der Ansatz den du da gewählt hast nicht unbedingt die beste Lösung ist." Ein Tipp am Rande, Datenkapselung und Aufbau von Schrittketten hilft einem seinen Code zu strukturieren. Dann behält man auch den Überblick über das was man da macht. Aber zurück zu den GOTOs: Die MISRA hat nicht umsonst folgende Regeln zur Programmierung von Quellcode in der amerikansichen Automobilindustrie aufgestellt.

• The goto statement shall not be used.

• The continue statement shall not be used.

• The break statement shall not be used (except to terminate the cases of a switch statement).

• These three rules are in the interests of good structured programming.

 

In anderen Programmiersprachen ist GOTO nicht umsonst verpönt. JAVA zum Beispiel hat auf die Implementierung des Schlüsselwortes GOTO verzichtet und kann damit sehr gut Leben. Leider haben wir in der Roboterprogrammierung ein Problem. Andere Programmiersprachen entwickeln sich weiter, oder werden weiterentwickelt. Beim Roboterprogrammieren ist die Programmiersprache leider nicht frei wählbar, sondern Herstellerabhängig. Und leider sehen die meisten Hersteller keinen Grund die uralten Guffelsprachen die sie da haben mal auf nen aktuellen Stand zu bringen. Aber das ist ein anderes Problem. Ich zähle nochmal kurz auf, warum Ihr keine GOTOs verwenden sollt.

 

• Schlecht lesbarer Code
• Erschwert die Fehlersuche
• Code meist nicht wiederverwertbar
• Schlecht erweiter- oder modifizierbar
• Fehleranfällige Programmierung
• Zerstört Codestrukturen -> Kein strukturierter Quellcode

So, und als einziges Positives Merkmal erwähnt ab und an mal ein unverbesserlicher: "Aber mit GOTOs kann in bestimmten Fällen...." Joa, in bestimmten Fällen, habe ich einen Vorteil und nehme mir dafür garantiert sechs Nachteile in kauf. Was wiegt da wohl schwerer.