PureBoard

NicTheQuick hat geschrieben:Es hat nichts mit guter Programmierung zu tun, dass man Goto immer vermeiden soll.

Finde ich schon weil Goto aus uralten BASIC-Zeiten stammt und viele Codes basierten darauf und es wurde langfristig festgestellt dass Wartbarkeit, Übersichtlichkeit und Strukturierung sehr schlecht sind wenn ohne Nachvollziehbarkeit überall hin gesprungen wird mal da mal dort und Sachen werden nicht sauber freigegeben oder abgeschlossen und es gibt aufgrunddessen Bugs ohne Ende die erstmal gefunden werden müssen. Dann stürzt es mal da ab ohne Grund. Weißt du warum BASIC so einen schlechten Ruf hat? Aufgrund von Spaghetticodes die entstanden sind. Dies ist nicht nur meine Behauptung sondern eine Tatsache siehe Beweise und Beispiele im Internet.

NicTheQuick hat geschrieben:In diesem Fall finde ich das Goto auch nicht schlimm.

Dann bist du in den 90er stehenbelieben.

NicTheQuick hat geschrieben:Aber wenn du professionelle Entwickler kennen würdest

Ich kenne welche die selbstständig oder in großen Unternehmen tätig sind und jeder würde das selbe sagen. Ich habe da auch mehrere Praktia gemacht. Auch in der Ausbildung oder im Studium lernt man sowas. Und in vielen Büchern stehts ebenso. Und in vielen Programmierforen ebenfalls.

NicTheQuick hat geschrieben:dass Goto auch im professionellen Bereich Verwendung findet

Hast du Beispiele für mich?

NicTheQuick hat geschrieben:Aber ich habe die Vermutung, dass in deinem Gehirn einfach "Goto" und "Spaghetticode" in der selben Schublade stecken

Das sagt sogar Wikipedia und viele andere Informationsquellen. Liest du garnichts oder bist du nicht bereit, über den Tellerrand zu schauen?

NicTheQuick hat geschrieben:Im Code von Sicro sehe ich kein bisschen Spaghetticode.

GOTO = Spaghetticode @ beisp. Wikipedia

Aber danke für deine Antwort und Meinung die ich lesen durfte.

Achja und Microsoft empfiehlt ebenfalls ...
Microsoft hat geschrieben:
Mit GoTo-Anweisungen wird der Code schwer verständlich, und die Pflege des Codes wird ebenfalls erschwert. Verwenden Sie stattdessen nach Möglichkeit eine Steuerungsstruktur.

Ich bin zwar kein Freund von Goto, aber soviel unfug hab ich noch nie gelesen
Lieber CodeCommander, lese mal bitte, bis zum Schluß, Sprunganweisung - Wikepedia.

Gruß
Thomas

@CodeCommander:
Wenn man richtig effizient programmieren möchte dann optimiert man sein Code hin und wieder in ASM und da kommt man nicht um das eine oder andere JMP herum
PS: Ich warte noch auf deine Lösung für den Code von Sicro, schließlich würde ich auch gerne sehen, wie so ein Code "durchgeplant" programmiert wird.

Ich bin ein Feind von Goto, aber soviel Verständnis hab ich noch nie gelesen
Lieber ts-soft, lese mal bitte, bis zum Schluß, Sprunganweisung - Wikepedia.

Ich zitiere einige Stellen für dich:

Dies führte zu unübersichtlichem „Spaghetticode“.

sprach für eine Abschaffung des GOTO-Befehls in allen höheren Programmiersprachen aus. Das ist ohne weiteres möglich, da nahezu jedes GOTO durch sogenannte Kontrollstruktur-Anweisungen wie DO, FOR oder WHILE ersetzt werden kann

wird dagegen die „Ein-Ausstiegspunkt“-Regel als obsolet angesehen

Aber ja ts-soft, es gibt nicht nur Contra sondern auch Pro-Argumente aber es gibt viel mehr Vorteile wenn man GOTO nicht verwendet beziehungsweise mehr Nachteile wenn man GOTO verwendet. Registrier du dich in einem Programmierforum einer höheren Programmiersprache und sage PRO GOTO. Die Leute lachen dich aus!

STARGÅTE hat geschrieben:Wenn man richtig effizient programmieren möchte dann optimiert man sein Code hin und wieder in ASM und da kommt man nicht um das eine oder andere JMP herum

Darum geht es doch nicht. Mir ist klar dass in ASM JMP oft benutzt wird. Es ist auch ein Hauptbestandteil dieser Sprache. Es geht hier um diese Sprache nämlich PB oder von mir aus auch andere Programmiersprachen. Da geht es darum dass der Quellcode übersichtlich, strukturiert und wartbar ist. Und GOTO ist ein NOGO! Da gibt es andere Mittel mit denen man strukturierte Codes aufbauen kann. Warum effektive Lösungen absichtlich nicht nutzen um GOTO zu benutzen? Ergibt keinen Sinn!

STARGÅTE hat geschrieben:Ich warte noch auf deine Lösung für den Code von Sicro, schließlich würde ich auch gerne sehen, wie so ein Code "durchgeplant" programmiert wird.

Warum sollte ich? Ich habe Beispiele genannt wie man es hätte besser machen können, warum soll ich einen ganzen Code schreiben? Nur um zu beweisen? Wenn du eine Software langsam findest, kann der Entwickler auch nicht sagen "mach besser". Auf welchem Planeten lebst du denn... Das ist doch nicht meine Aufgabe. Wenn Leute der Meinung sind GOTO unbedingt benutzen zu müssen können sie machen aber ich habe lediglich meine Meinung gesagt. Ist das verboten? Meinungsfreiheit, ob es dir passt oder nicht.

CodeCommander hat geschrieben:Warum nicht einfach eine Variable nutzen

Ich wollte eine Verschachtelung einsparen.
Bei komplexerem Code würde mit Variable und If-Block evtl. die Übersichtlichkeit leiden.

CodeCommander hat geschrieben:in zwei Prozeduren teilen

Code-Teile aus dem Zusammenhang zu reißen, fördert nicht immer die Übersichtlichkeit, vor allem nicht bei so einem kleinem Code. So wie der Code ist, kann man ihn von oben bis nach unten lesen, um den Ablauf nachzuvollziehen, ohne zwischendrin zu einer anderen Procedure springen zu müssen.

CodeCommander hat geschrieben:bitte versuche vor dem Schreiben deines Codes zu planen und nicht einfach los zu programmieren

Welcher Code-Teil spricht den dagegen, dass ich eine Planung durchgeführt habe?

CodeCommander hat geschrieben:Ich vermute mal du hast auch noch nie OOP programmiert?

Ungefähr 5 Jahre in Visual Basic 6.0 . Ist aber schon wieder ca. 10 Jahre her.

CodeCommander hat geschrieben:Bitte keinen HATE aber wenn ein professioneller Entwickler den Code sehen würde dann ... ich sage nur fremdschämen.

Oh je, Weltuntergang ... Was ist den an dem Code schlecht, wenn man von dem Goto-Befehl absieht? Ist er dadurch für dich unübersichtlicher?
Hier im Thread geht es um Goto-Varianten und nicht darum, wie man es ohne macht.

CodeCommander hat geschrieben:Einige meinen zwar es gibt sinnvolle Goto Varianten die viel besser sind aber mal erlich das sagen nur die Leute, die nicht wissen, wie man es richtig machen kann.

Eine Goto-Variante ist weder richtig noch falsch. Solange der Code übersichtlich und fehlerfrei bleibt, spricht nichts gegen Goto, meiner Meinung nach.

Sicro hat geschrieben:Bei komplexerem Code würde mit Variable und If-Block evtl. die Übersichtlichkeit leiden.

Man soll auch nicht alles in einer Prozedur reinpacken sondern in anderen Prozeduren aufteilen. Wer eine Prozedur mit 500 Zeilen erstellt, hat das Prinzip einer sauberen Code-Strukturierung nicht verstanden.

Sicro hat geschrieben:Code-Teile aus dem Zusammenhang zu reißen, fördert nicht immer die Übersichtlichkeit, vor allem nicht bei so einem kleinem Code.

Das sagen professionelle Entwickler was anderes. Kennst du Wiederverwendung von Funktionen oder Methoden? Es gibt Code-Teile die man gut auslagern kann dann fragt man nur die Funktion ab und fertig ohne viel extra Code in der Prozedur zu haben. Außerdem können Teile des Codes automatisiert werden und spart Code. Dein Code ist an sich okay nur Goto stört mich sehr wie du es festgestellt hast. Ich bin nur der Meinung dass man ohne Goto es auch hätte besser machen können.

Sicro hat geschrieben:So wie der Code ist, kann man ihn von oben bis nach unten lesen, ohne zwischendrin zu einer anderen Procedure springen zu müssen.

Es ist nicht immer notwendig, in eine andere Prozedur zu springen weil du anhand des Funktionsnamens schon weißt was die Funktion macht. Z.B. GetDayOfWeekAsString() hast du auch ausgelagert und musst nicht in die Prozedur springen warum auch. Es sei denn du willst die Funktion anpassen.

Sicro hat geschrieben:Ungefähr 5 Jahre in Visual Basic 6.0

Ungefähr 5 Jahre in Visual Basic 6.0 vor 13 Jahren? Ich hoffe du hast es nicht schon verlernt.

Sicro hat geschrieben:Eine Goto-Variante ist weder richtig noch falsch. Solange der Code übersichtlich und fehlerfrei bleibt, spricht nichts gegen Goto, meiner Meinung nach.

Das ist das Problem. Es ist unübersichtlicher und fehleranfälliger und schlechter wartbarer als heutige Strukturenmöglichkeiten. Wie oft laß man in Foren dass bei einer Goto-Verwendung die Ursache des Problems war, dass Goto Schuld daran war? Es ist doch dasselbe wie wenn jemand Enableexplicit nicht benutzt und sich wundert warum etwas nicht funktoniert und dann stellt man fest dass ein Variablennamen falsch geschrieben wurde. Du kannst mir nicht erzählen dass du bei Goto 0 Fehler machst und vorausschauend weißt was alles passieren kann. Da passieren nicht nachvollziehbaren und merkwürdigen Sachen. Ich will dir davon nicht abraten, du kannst gerne weiter goten aber es ist nicht ohne Grund so, dass Goto einen sehr schlechten Ruf hat und möglichst vermieden wird. In einigen Code Guidelines wird sogar explizit davon abgeraten. Ich halte mich jedenfalls an das Wissen der anderen Leute. Oder meinst du die haben alle Unrecht? Dann meinst du sicherlich dass Albert Einstein auch nur Müll labert? Aber falls du der Meinung bist es ist bis jetzt noch nie passiert dass irgendwelche Fehler auftraten die du nicht nachvollziehen konntest und es ist weiterhin problemlos, mit Gotos zu arbeiten, dann fährst du sicherlich auch Auto ohne Gurt nur weil du noch nie einen Autounfall hattest? Warum musst du dich anschnallen wenn eh nichts passiert und du immer gut fährst?

Ich hab mich am Anfang nich getraut nachdem ich die Gegenmeinungen gelesen hab.
Aber nach mehren Antworten muss ich doch sagen das ich auch kein Freund von Goto bin.
Als ich mit Pb anfing wurde mir mal gesagt ne ich glaub ich hab das mal irgendwo gelesen das man Goto nicht benutzen soll.
Anfangs hab ich auch gotos gemacht fand ich schon sehr frickelig und half mir es zu verstehen.
So ähnlich funktioniert es mit Procedure auch oder? Also prinzinpiel
Aber gotos hab ich schon lange aufgehört. Finde ich auch ohne besser.
@CodeCommander
Schöne Worte und bin deine Meinung. Ich hätte es nicht besser sagen können.
@Alle
Vieleicht solltet ihr Beispiele nennen wo man Umsetzung ohne Goto nicht möglich ist?
Das wär doch was.

@CodeCommander

Ich sag da nur "Größer" ist nicht immer Besser. Goto sinnvoll eingesetzt erspart eine „Menge“ Code und Rechenzyklen.
Wer damit zu Recht kommt wird es immer wieder benutzen, egal in welcher Sprache. Wer das Goto so vehement wie Du ablehnt, der sollte sich mal eingehend mit dem „Urschleim“ für die Programmierung befassen. (zB.Assembler)
-->Und Spagetti kommen bei mir in den Topf.
In MS Basic konnte man auch strukturiert Programmieren, man musste es halt Lernen, oder konntest Du es gleich.
Beim Studium musste ich auch noch einmal mit TurboPascal anfangen. Und viele C+ „Programmierer“ die mit mir die Bank gedrückt haben sind ganz schnell ins schleudern geraten beim „Umdenken“.
Die Lanze zu brechen gegen GOTO ist so als wenn Don Quijote die Windmühlen abschaffen wollte.

Ich unterstütze die Meinung von SDL und auch von Nino.
Hier sieht man Leute die praktische Erfahrung haben, keine Blender.
Wer effektiv zum Ziel kommen will darf nicht wählerisch sein in der Wahl seiner Mittel.
Den direkten Weg gehen !
Was nutzt es mich in meinen Code meine Philosophie einzubauen, boah, toll was ich alles tolles kann.
Debug mal einen "tollen" Code, vielleicht nach einem Jahr.
Dann ist die Freude groß, wenn man ihn noch zügig lesen kann.
Es hat auch absolut nichts mit Dummheit zu tun einen Code möglichst einfach halten zu wollen.
Es kann ja auch mal sein das andere den Code warten müssen !
Habe ich einen Code der mir verbesserungswürdig erscheint, stelle ich ihn hier in´s Forum.
Schon wird er besser.
Einfacher geht´s doch nicht mehr !

Ich glaube CodeCommander kommt aus der Projektmanagement-Ecke
und da kann ich ihn schon verstehen das man nicht einfach so programmiert wie in seiner Freizeit.
Da ist Team-Arbeit angesagt und müssen sich an Standards und festgelegte Codedesigns halten.
Da geht es in erster linie darum das jedes Teammitglied sauberen und einheitlichen Code schreibt und jeder damit arbeiten kann ohne Zusatzaufwand der für das Unternehmen Geld kostet.
Ich glaube CodeCommander ist zu sehr unternehmensbezogen und kann nicht einfach "loslassen".
Wie auch immer jedem das seine.