goto-befehl in delphi?

[Der_Unwissende]

Nun ja, ist ja schön was mal gelehrt wurde.
Aber heutige Programme lassen sich nicht mehr sinnvoll als Struktogramme modellieren. Also ich würde gerne eure Nebenläufigen Struktogramme sehen, wie sieht denn hier ein Windowsbotschaft aus?

Ich denke Struktogramme sollten genau so wenig wie etwas anderes als Möglichkeit gesehen werden aussagen über den Code zu machen. Alles was es hier gibt verfolgt ein sehr spezielles Ziel (z.B. auch jedes einzelne UML Diagramm).
Das ich Code strukturieren sollte versteht sich von selbst, aber das wie bietet eine Menge Möglichkeiten. Solange der Code die wichtigsten Ziele der Softwaretechnik erfüllt (Robust, Wartbar, Einfach, Sicher, hab sie nicht alle im Kopf) wird keiner auf ein Struktogramm bestehen. Vorallem ist die Kenntnis des Codes als white-box (was passiert in dem Programm genau) garnichts was ich unbedingt wissen will. Wenn man etwas mit Komponenten (meine hier Komponenten, nicht TComponent!) arbeitet, dann ist dies eine große black-box. Abstraktion lautet eines der Hauptziele (der OO). Hier wird wiederverwendbarkeit erreich (was für Komponenten sehr wichtig ist).

Zudem gilt was Luckie schon sagte, es werden Sachen gelehrt, die realitätsfremd sind. Aber selbst bei den realitätsnahen sollte man drauf achten, dass sich die Welt von Zeit zu Zeit einfach mal weiter dreht.

[alcaeus]

Traumhaft diese Diskussion Ich ueberlege mal, was ich bis jetzt verwendet habe:
break: ja.
continue: ja.
goto: ja.
exit: ja.

Ich wuerde sagen, jeder Befehl hat seine Daseinsberechtigung. Ich halte mich auch von gotos fern, soweit es geht, und genauso gehts mir mit breaks und exits.
Wenn ich die Wahl habe, eine for-Schleife und ein break, oder eben eine While-Schleife mit 2 Abbruchbedingungen zu verwenden, dann nehme ich oft eine while-Schleife, ganz einfach weil man dadurch sofort sieht, warum abgebrochen wird. Wenn ich aber im Fehlerfall eine Fehlermeldung ausgeben will, dann wird ganz einfach ein break oder ein exit nach der Fehlermeldung platziert.

Und bezueglich continue, ich frage mich wo da der grossartige Unterschied sein soll:

Delphi-Quellcode:

for i := 1 to Length(s) do
begin
  if (s[i] <> 'f') then
    DoSomething(s[i]);
end;

Delphi-Quellcode:

for i := 1 Length(s) do
begin
  if (s[i] = 'f') then
    continue;
  DoSomething(s[i]);
end;

Vor allem wenn anstatt DoSomething() mehrere Anweisungen kommen, versuche ich durch die Verwendung von continue eine Einrueckungsstufe zu sparen. Manchmal gehts einfach nicht anders und Code wird ein paar viele Stufen eingerueckt; wenn man sich da eine davon sparen kann, und dafuer ein continue verwendet, geht die Welt bestimmt nicht unter. Ausserdem ist die continue-Schreibweise nur unwesentlich oder sogar ueberhaupt nicht schwerer lesbar als die erste Variante.

Just my $.02

Greetz
alcaeus

PS@ Unwissender: Vorsicht, Struktogramme haben heute noch eine grosse Wichtigkeit, und UML-Diagramme haben mit Struktogrammen nicht wirklich viel zu tun, also wuerde ich die beiden auch nicht so vergleichen wie du es getan hast. Und was die Ziele der Softwaretechnik betrifft, so schiesst die selbst manchmal am Ziel vorbei; die Vorlesung gehoert zu den schwachsinnigsten und unrealistischsten (wat weiss ich wie das geschrieben wird ) die ich in den bisherigen 2 Studien-Semestern hoeren musste

[Der_Unwissende]

Zitat von alcaeus:

PS@ Unwissender: Vorsicht, Struktogramme haben heute noch eine grosse Wichtigkeit, und UML-Diagramme haben mit Struktogrammen nicht wirklich viel zu tun, also wuerde ich die beiden auch nicht so vergleichen wie du es getan hast

Natürlich haben UML und Struktogramme nicht wirklich viel gemeinsam, aber eben guter Code (lesbarer, wartbarer, was auch immer) und die Möglichkeit ihn in einem Struktogramm darstellen zu können auch nicht. Ein Struktogramm ist einfach eine Möglichkeit etwas zu veranschaulichen.
Also ich glaube Struktogramme (in der einfachen standardform) haben kaum wirklichen Nutzen. Den Ablauf eines Programms mit Hilfe eines Struktogramms zu modellieren dürfte doch nun wirklich an nebenläufigen Prozessen scheitern. Wie genau möchtest du diese denn im Struktogramm darstellen? Wenn es dann noch zur Synchronisierung kommt...
Jedenfalls ist ein Struktogramm doch sehr sequentiell aufgebaut. Nur je mehr Kerne eine CPU hat, desto weniger wird das wohl jmd. nutzen. Ist nur meine persönliche Meinung!

Zitat von alcaeus:

Und was die Ziele der Softwaretechnik betrifft, so schiesst die selbst manchmal am Ziel vorbei; die Vorlesung gehoert zu den schwachsinnigsten und unrealistischsten die ich in den bisherigen 2 Studien-Semestern hoeren musste

Wow, is ja interssant. Sorry, aber das ist doch nicht dein Ernst, oder? Ich meine klar die eine weltweite Vorlesung die das komplette Gebiet der SWT abdeckt und über die das Wort überhaupt erst definiert wird oder wie?
Mag ja sein, dass du da eine schlechte VL gehört hast (oder was weiß ich wie viele), gewöhn dich schon mal daran, das passiert. Zudem haben viele Themengebiete nicht wirklich was mit dem zu tun, was man erwartet.

Aber die SWT an sich hat durchaus ihre Rechtfertigunng. Ich denke bei der SWT ist das Problem, dass ein gutes Design unter anderem auf Erfahrungen basiert, die kann man nun einmal schlecht einem Studenten beibringen. Zudem kommt noch hinzu, dass gerade an der Uni wohl kaum all zu große Projekte anfallen. Und letztlich bleibt auch die Frage der Konsequenzen. Also in meiner Studienzeit mussten wir nie über die Dauer eines Projekts verhandeln. Die Größe war auf ein Semester ausgelegt und nun ja, man hatte ein Semester Zeit. Das Problem stand von Anfang an fest, Kunden gab es keine, was soll ich sagen, völlig realitätsnah halt. Zudem hat man noch eine Betreuung und der Dozent/Tutor der das Projekt abnimmt ist auch noch Informatiker.
Wenn du mal mit einem nicht-Informatiker als Kunden zu tun hattest/hast, wirst du schnell merken warum es gewisse Techniken gibt (die dann der SWT zugerechnet werden). Anders als bei mir an der Uni, laufen Projekte auch mal weiter. Es kann sein dass du eine SW X entwickelst, die ein Gerät A steuert und Ergebnisse auswertet. Dein Auftraggeber entwickelt dann Gerät B (hat in ein paar Punkten Gemeinsamkeiten mit A) und möchte eine SW XY, die sowohl mit A als auch B zusammen arbeitet. Hier zeigt sich dann, wie gut du gearbeitet hast (wie gut du Dinge wieder verwenden kannst). Das schlägt sich auf die benötigte Zeit, die Kosten, die Zufriedenheit des Kunden und deine Zukunft in einer Firma (bzw. vielleicht auch dein Gehalt) wieder. Natürlich nicht immer und überall gleich, aber so grob halt.
Ist aber ein eigenes Thema, ich bleib dabei, ich stimme Luckie weiterhin zu, Uni und Realität existieren zeitweise parallel und wissen nichts voneinander.

[Peinhard]

Zitat von Florian Bernd:

Es geht auch mit verschachtelten Schleifen, sogar ohne ein extra Flag zu setzen:

Delphi-Quellcode:

var 
  i, i2, i3: integer;
begin
  for i := 0 to 10 do
  begin
    for i2 := 0 to 20 do
    begin
      for i3 := 0 to 30 do
      begin
        if i3 = 15 then
          break;
      end;
      if (i3 = 15) and (i2 = 10) then
        break;
    end;
    if (i3 = 15) and (i2 = 10) and (i = 5) then
      break;
  end;
end;

Wieso denn nicht einfach die Zählervariable verwenden, die sowieso in(de)crementiert wird?

Weil sie 'per definitionem' außerhalb der Schleife 'undefiniert' ist, dh irgendeinen Wert haben kann. Die erste Abfrage von i3 ist also noch 'sicher', die zweite und dritte jedoch nicht mehr.

[Luckie]

Zitat von Michael Habbe:

@Jasacul

Du hattest da einen Fehler drin.

Delphi-Quellcode:

fehler:='';
if Belegnummer <> 0 then
  fehler:='Fehler: Belegnummer'
else
  if Belegdatum = 0 then
    fehler:='Fehler: Belegdatum'
  else
    if x = 0 then
      fehler:='Fehler: x'
    else
      if y = 0 then
        fehler:='Fehler: y'
      else
        ; // mache was, es ist alles ok, kein Fehler aufgetreten

result := fehler;

Und warum hatte er da einen Fehler drinne? Weil es einfach unübersichtlich ist. Jetzt stell dir den Code mal noch mit 10 bis 15 Zeilen Code zwischen den ifs vor.

[Jasocul]

Klärt mich auf. Wo ist der Fehler?
Wenn die Belegnummer ungleich Null ist, habe ich einen Fehler vorliegen?
Ich habe gestern schon die Kritik von Michael Habbe gelesen, dachte mir aber, dass das offensichtlich ist, dass er nicht Recht hat. (Achtung! Jetzt kommt etwas, das nicht ganz ernst gemeint ist!) Aber wenn Luckie das auch übersieht, wundert es mich nicht, dass so viele Goto verwenden müssen, um ihren Code zu überschauen.

Ich glaube, jetzt verzieh ich mich in meinen Bunker, bevor ich ernsthaften Schaden nehme.

[Michael Habbe]

Zitat von Jasocul:

Klärt mich auf. Wo ist der Fehler?

Delphi-Quellcode:

fehler:='';
if Belegnummer <> 0 then
  if Belegdatum = 0 then
    fehler:='Fehler: Belegdatum'
  else
    if x = 0 then
      fehler:='Fehler: x'
    else
      if y = 0 then
        fehler:='Fehler: y'
else
  fehler:='Fehler: Belegnummer';
if fehler = '' then
  // mache was, es ist alles ok
Result:=fehler;

Der Fehler liegt im letzten else. Gebe mal für alle Variablen den Wert <> 0, dann kommt der Fehler "Belegnummer". Wenn die Belegnummer aber null ist, wird sofort aus dem Vergleich herausgesprungen, d. h. zum "Fehler:Belegnummer" kommt er nicht. Wenn Du das aber haben willst, musst Du um die erste Bedingung begin und end setzen.

Delphi-Quellcode:

fehler:='';
if Belegnummer <> 0 then
begin
  if Belegdatum = 0 then
    fehler:='Fehler: Belegdatum'
  else
    if x = 0 then
      fehler:='Fehler: x'
    else
      if y = 0 then
        fehler:='Fehler: y'
end
else
  fehler:='Fehler: Belegnummer';
if fehler = '' then
  // mache was, es ist alles ok
Result:=fehler;

Deshalb habe ich das geändert, allerdings muss in meinem Beispiel das "<>" geändert in "=" werden, das hatte ich übersehen.

Zitat von Michael Habbe:

Delphi-Quellcode:

fehler:='';
if Belegnummer = 0 then // hier hatte ich den Fehler "<>" 
  fehler:='Fehler: Belegnummer'
else
  if Belegdatum = 0 then
    fehler:='Fehler: Belegdatum'
  else
    if x = 0 then
      fehler:='Fehler: x'
    else
      if y = 0 then
        fehler:='Fehler: y'
      else
        ; // mache was, es ist alles ok, kein Fehler aufgetreten
result := fehler;

Zitat von Luckie:

Und warum hatte er da einen Fehler drinne? Weil es einfach unübersichtlich ist. Jetzt stell dir den Code mal noch mit 10 bis 15 Zeilen Code zwischen den ifs vor.

Also unübersichtlich kann ich diese paar Zeilen nicht nennen.
Ich habe in meinen Projekten diese Verschachtelungen mit viel Code zwischen den begins und ends. Diese erstrecken sich teilweise über mehrere Seiten. Die Voraussetzung für die Übersichtlichkeit ist natürlich, dass man alles brav ordentlich einrückt. Dann muss man nur mit dem Cursor nach oben fahren, um z.B. zum end das begin zu finden.

[Jasocul]

Stimmt. Hatte mich durch dein "<>" im ersten if verwirren lassen. habe also das else nach dem letzten if y= 0 vergessen. Oder man macht es so, wie du.
Und ich gestehe, dass mir diesee Fehler mit Luckies Code vermutlich nicht passiert wäre.

[Go2EITS]

@Alle
Noch ein obendraufsetz:

Was ist mit

Delphi-Quellcode:

Start:               //Label Start
readln(f,Daten);     //Aus File in die Variable DATEN Zeile einlesen
if EOF(f) then if daten:='' then goto Start; //Daten ist leer, kein EOF also springe ich zu Start.

An der Seitenzahl dieses Threads habe ich gesehen, dass jeder seine Meinung zu Goto, Break und Exit hat.Manchmal ist es angebracht, manchmal nicht. Es ist einfach Geschmackssache. Ich finde meine Lösung bei meinem Beispiel so sinnvoll.

Haut Ihr mich jetzt verbal???

Beste Grüße an die DP!

[mkinzler]

Nein, aber wenn du uns sagst, wo du wohnst ...