next topic »

[Reply #15 on:]

Ich riskiers mal, daß Ihr mich gleich steinigt.....

Ich bin ein try & error Autodidakt und hab auch schon GOTO verwendet.
 
Nach diesem Beitrag hab ich beschlossen den "Anonymen Goto-Programmierern" beizutreten und das GOTO nicht mehr zu verwenden.

Aber.... Warum???
Was spricht dagegen?

[Reply #16 on:]

Du konntest mir ja nicht einfach glauben, was?

Hätt ja auch nur ein Weana Schmäh sein können... 

[Reply #17 on:]

Ich riskiers mal, daß Ihr mich gleich steinigt.....

Ich bin ein try & error Autodidakt und hab auch schon GOTO verwendet.
 
Nach diesem Beitrag hab ich beschlossen den "Anonymen Goto-Programmierern" beizutreten und das GOTO nicht mehr zu verwenden.

Aber.... Warum???
Was spricht dagegen?

http://de.wikipedia.org/wiki/Spaghetticode
GOTOs machen den Code unübersichtlicher und schwerer lesbar. Und es gibt IMMER einen Lösungsweg der ohne GOTO auskommt. Was ist die logische Konsequenz: kein GOTO verwenden.

Ich gebe zu, auch ich habe schon mal GOTO verwendet. Das war bei meinen ersten Programmierversuchen auf dem Commodore 64. Der dort verwendete BASIC Dialekt zwang einen aber dazu. Nach dreissig Jahren und fast einem dutzend Programmiersprachen später kann ich sagen: es hat sich seitdem für mich nicht einmal ergeben, dass ein GOTO sinnvoll oder gar nötig gewesen wäre.

[Reply #18 on:]

Als generelle Kurz-vor-Ende - Marke, könnte ich mir Situationen ausdenken, wo ein goto evtl. Sinn machen könnte.
( Wenn z.B. vor dem return noch was aufzuräumen ist )

Die Arduino Referenz zum goto ist eigentlich eine ausgewogene Formulierung

throw ( sowie try/catch ) hab ich auf dem Arduino bisher nicht gesehen. Wenn man sowas ähnliches zu brauchen glaubt, muss man allerdings berücksichtigen, dass man mit goto nicht aus einer Funktion herausspringen kann, und erst recht nicht mitten in eine andere hinein. Lässt sich also auch nicht durch goto realisieren.

Für wilde Hin und Her - Sprünge, und um Schleifen zu erzeugen, taugen goto wirklich nicht.

Man sollte auch keine "Programmablaufpläne" denken, oder gar aufmalen (die mit den rautenförmigen if - Abfragen und vielen langen Strichen auf andere Blätter)

[Reply #19 on:]

hi,

auch wenn ich das mit dem return in die diskussion gebracht habe:

der typ, der früher im thread das return abgelehnt hat (Ihr wißt schon, der, der nicht einmal wußte, was ein break macht), hat eigentlich nicht unrecht.
ein goto hinterlässt oft eine recht undefinierte situation, aber ein return macht ja nichts anderes als ein goto function_end, wenn function_end: am ende der funktion steht.

berechtigt ist das return, wenn damit der rückgabewert der funktion festgelegt wird. danach kann nichts mehr kommen, weil ja damit die funktion ihren zweck erfüllt hat. ebenso bei mehreren returns in if-abfragen.

inzwischen denke ich schon eher so wie dieser typ vom anfang des threads (Ihr wißt schon, der, der nicht einmal wußte, was ein break macht), daß man mit bedingungen sauberer programmiert. hab' ich eigentlich auch immer gemacht, ein return ist bei mir zur festlegung des rückgabewerts, aber die fragestellung hat mich verleitet.

wenn man überlegt programmiert und nach einem goto oder return nichts hinterläßt, das schwierigkeiten macht, kann man auch beides verwenden, aber wenn man ein goto ablehnt, hat auch ein return ohne zuweisung nichts im code verloren.

gruß stefan

[Reply #20 on:]

Puristen lehnen auch ein break; oder continue; in Schleifen ab, weil man das gut durch ein if und zwei an den richtigen Stellen gesetzten geschweiften Klammern simulieren kann. (Sie nennen das natürlich ein "verkapptes goto")
Wenn man die Klammern aber nicht richtig einrückt, ist das Ergebnis auch nicht lesbarer als eine gepflegte Portion Spaghetti-Code.

Wenn man die schliessenden Klammern zusätzlich zum richtigen Einrücken noch mit Kommentaren versehen muss, um sich an die Logik zu erinnern

Code:

          ...
        } // end while
      }  // end else "Error"
    }  // end äussere Schleife 1
    // keine Ahnung ob dieser Code nicht eigentlich woanders hingehört.
  } end "if there is something to do"
}  // end function 

... kann man die Qualen eines Anonymen Goto-Programmierers nachempfinden, der weiß: es bleibt nicht beim simplen return;, Rückfall ist Rückfall.


Ausserdem, auch Funktionen mit Rückgabewert kann man so schreiben, dass sie nur am unteren Ende mit

Code:

  ...
  return retval;
}   

verlassen werden.

[Reply #21 on:]

der typ, der früher im thread das return abgelehnt hat (Ihr wißt schon, der, der nicht einmal wußte, was ein break macht),

Danke

inzwischen denke ich schon eher so wie dieser typ vom anfang des threads (Ihr wißt schon, der, der nicht einmal wußte, was ein break macht),

Vielen Herzlichen Dank

Stefan, ist alles ironisch und scherzhaft gemeint. "Tratzn" unter Freunden.

Einmal eine Gegenüberstellung eines Microsoft!!!!-Basic GOTO wie im C64 oder VC20 mit einem ANSI-C

Schleife:

Code:

20 IF (eingangwert <> 1) GOTO 20

in C:

Code:

While (eingabewert != 1){}

Auswahl

Code:

10 Eingangewert lesen.
20 IF (eingangwert = 1) GOTO 100
30 IF (eingangwert = 2) GOTO 200
40 IF (eingangwert = 3) GOTO 300
50 GOTO 10
...
100 Tu irgenwas
110 GOTO 10
...
200 Tu irgenwas anderes
210 GOTO 10
...
300 Tu irgenwas drittes
310 GOTO 10

in C:

Code:

switch (eingangwert)
  {
  case 1:
  Tu irgenwas;
  case 2:
  Tu irgenwas anderes;
  case 3:
  Tu irgenwas drittes;
  }

Basic

Code:

20 GOSUB 100
...
30 GOSUB 100
...
100 Tu irgendwas
110 RETURN

C-Variante:

Code:

c = meinefunktion (a,b)
...
int meinefunktion (int a, int b)
  {
  Tue irgendwas;
  return(rückgabewert);
  }

In wenigen Worten.
In C machen die geschwungenen Klammern, die einen Codeblock definieren, verschiedene Kontrollstrukturen (if-else, while, do while, switch case) und die möglichkeit Funktionen selbst zu definieren, den Einsatz von GOTO überflüssig.

Grüße Uwe

[Reply #22 on:]

So weit ich Eure Begründungen verstanden habe, geht es bei der Ablehnung des Goto mehr ums Thema Spaghetticode.
Also um die Übersichtlichkeit und Lesbarkeit des Codes.
In meinem speziellen Fall wäre das Goto (zwar durch Verwendung von if und zusätzlichen Variablen) umgehbar gewesen, macht (meines Erachtens) den Code aber effektiv "lesbarer".

Wie sieht es nun aber aus technischer Sicht aus.
Beeinflusst das Goto die Geschwindigkeit oder den Ram-Verbrauch bei der Ausführung negativ?

[Reply #23 on:]

Wie sieht es nun aber aus technischer Sicht aus.
Beeinflusst das Goto die Geschwindigkeit oder den Ram-Verbrauch bei der Ausführung negativ?

Nein, natürlich nicht.

Der klassische Anwendungsfall für ein goto unter C/C++ ist üblicherweise der Abbruch aus einer verschachtelten Konstruktion von for-Schleifen.

Code:

for ...
{
  for ...
  {
    for ...
    {
      if(Abbruchbedingung)
        goto funktionsende;
    }
  }
}
funktionsende:

Aus so einer Konstruktion kommst Du nur mit goto elegant heraus.

Klar, mit einigen wenig eleganten Klimmzügen ginge es auch ohne...

Aber es gibt eben auch Fälle, in denen ein einzelnes goto die Lesbarkeit und Verständlichkeit des Codes erhöhen kann.

[Reply #24 on:]

Stefan, ist alles ironisch und scherzhaft gemeint. "Tratzn" unter Freunden.

ein gaanz liebes winken aus wien über den brenner.

gruß stefan