goto-befehl in delphi?

[Oxmyx]

Zitat:

Zitat von omata

Da überlegt man sich den positiven Fall (nicht den Negativen), hab ich ja oben schon geschrieben.

Wie würdest du das konkret machen? Mit Bedingungen, wie in Luckies Beispiel? Mit einem Code, der zur Hälfte aus Exceptions besteht?

[Luckie]

Zitat:

Zitat von omata

Zitat:

Zitat von Luckie

Ging nicht, weil immer eine andere Fehlermeldung kommen musste.

Für solche Fälle gibt es Exceptions.

Und eine Exception ist im Endeffekt kein Sprungbefehl?

[omata]

Wie man sowas konkret löst? Naja, es ist eigentlich blödsinn sich hier auf solch eine Diskussion einzulassen. Weil ihr euch einfach ein paar Zeilen Code zusammen stellt, der völlig aus der Luft gegriffen und speziell mit Schwierigkeiten bepackt ist. Normalerweise löst man ein Problem und da muss man sich vielleicht mal fragen, ob man nicht vielleicht schon einen grundsätzlichen Desginfehler gemacht hat. Und man schon an ganz anderer Stelle etwas ändern muss, damit sich der Knoten der Problemstelle löst.

Aber nun gut, versuchen wir es mal mit der eingeschrängten Sichtweise...

Zitat:

Zitat von Luckie

Code:

if Belegnummer = 0 then
  exit
if Belegdatum = 0 then
  exit
if x = 0 then
  exit
if y = 0 then
  exit

wenn man da einen Rückgabewert realisieren muss, sieht das sowieso schonmal ganz anders aus...

Code:

if Belegnummer = 0 then begin
  Result:='Fehler: Belegnummer';
  exit;
end;
if Belegdatum = 0 then begin
  Result:='Fehler: Belegdatum';
  exit;
end;
if x = 0 then begin
  Result:='Fehler: x';
  exit;
end;
if y = 0 then begin
  Result:='Fehler y';
  exit;
end;

und nunmal ohne exit...

Code:

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';

if fehler = '' then
  // mache was, es ist alles ok
Result:=fehler;

Zitat:

Zitat von Luckie

Und eine Exception ist im Endeffekt kein Sprungbefehl?

Ich habe nie behauptet, das Exceptions keine Sprungbefehle sind. Aber meine Aussage, um die es in Wirklichkeit ging nämlich das man kein exit, goto, break braucht, wird dadurch nicht entkräftet.

Gruss
Thorsten

[JasonDX]

Zitat:

Zitat von omata

Aber meine Aussage, um die es in Wirklichkeit ging nämlich das man kein exit, goto, break braucht, wird dadurch nicht entkräftet.

Natürlich nicht.
Aber ums mal so zu sagen: Ich komme in einem Programm auch ohne goto, break und exit aus. Ich komme auch ohne for- und while-schleifen aus, und kann auch auf if-abfragen verzichten. Ich kann jegliches Programmkonstrukt hinter mir lassen, weil es mir nicht gefällt oder ich es verabscheue.
Aber lediglich, weil sie nicht in meinen Verwendungszweck fallen, sind sie noch lange nicht überflüssig oder unbrauchbar. Ich verwende exits und breaks, genauso wie for- und whileschleifen, sowie if-abfragen. Natürlich kann ich jedes Problem ohne sie lösen, aber mir fällt die Problemlösung leichter, wenn ich sie verwende. Und genau damit wäre diese Aussage

Zitat:

Zitat von omata

folgende Befehle sind überflüssig: exit, goto, break

widerlegt. Mir helfen sie bei meiner Problemlösung und haben somit ihre Daseinsberechtigung.

greetz & gute nacht
Mike

[Neotracer64]

Argument Nr.1 Wartbarkeit/Übersichtlichkeit:

Benutze "goto, break, exit" dann, wenn es die Wartbarkeit/Übersichtlichkeit begünstigt und sonst einfach nicht. Je nachdem wie es besser passt.

Argument Nr.2 ordentliche strukturierte Programmierung

Sollte man lernen - Ohne Frage - Aber ein erfahrener Entwickler, der ein goto in einem bestimmten Fall als einfacher/ besser/schneller/wartbarer hält kann das doch wohl einbauen. Es tangiert ja sonst keinen.

[Real_Thunder]

Meine Rede....

und zwischen einem Goto oder einem Break / Exit, ist ja auch noch ein Unterschied,

in alten programmiersprachen gab es wenig bis keie Alternativen zum GOTO

Je mehr jemand ahnung vom Programmieren hat, desto Struckturierter werden die Probramme..
Nach und nach werden die Goto's dann auch weniger...
Spätestens wenn man sich nach der 20. Sprungmarke nicht mehr zurechtfindet...

Schaut mal auf die Überschrift.

Es war nur ne Frage ob es geht.. und in wie fern es Sinnvoll ist...
Eshat schon einen grung, weshalb die Befehle noch existieren...
jemand der seinen Source kennt.. und weiß das er mit einem goto 30 Zeilen Code Einsparen kann..

man, dann soll er es reinsetzten....

und von der logik her ist goto leicht zu verstehen..... und sprungmarken sind zu 100 % NÖTIG

ob es nun SUB Routinen im Sinne von Proceduren oder Funktionen sind.....

und man kann nicht erwarten das gleich jeder der nicht lange prgrammiert, sich die Programme von vorne weg zurechtschreibt, dass er keine abfrangen in einer schleife hat...

wenn ich ne bestimmte varible in einem array suche, dann kann ich dieses mit einer schleife durchgehen, und beim richtigen break setzten...

Wenn man das ganze Weiterführt.. dann kann man komplette If Struckturen überflüssig nennen..

Dazu gibt es auch viele alternativen....


Naja ich denke mal der Ganze kram ist genug Durchgekaut worden.....

[Hansa]

Mann mann, sogar mit Moderatorenhilfe werden Argumente gegen eine strukturierte Programmierung gesammelt. Ich glaub ich bin im falschen Film. :shock:

Zitat:

Zitat von Luckie

Und was ist ein Exit oder Break, wenn nicht ein goto?

Luckie, das könnte man tatsächlich als eine Art von goto ansehen ! Aber das kann man doch nicht als Argument nutzen, solche Sachen zu forcieren. Exit oder Break sind lokal beschränkt und man kann sich höchstens in einer function/Procedure oder Schleife selber überholen. Mit einem Goto springe ich notfalls mitten in einen uninitialisierten Prozess. Omata geht ja noch weiter als ich. Der war/ist bestimmt auf Uni. Da lernt man, solche Sachen am Besten nicht zu benutzen. Jetzt kommen nooch einige und sagen : goto gehört zum Sprachumfang, warum soll ich es denn dann nicht benutzen ? Ganz einfach, sofern man weiß, warum das überhaupt in Pascal drin ist : es ist lediglich ein Zugeständnis an Umsteiger, hauptsächlich von Basic her. 1972 hat Wirth die ersten Studenten an Pascal drangelassen. Die mußten dann lernen, wie sie die Gotos aus ihren Basic Programmen eliminieren, um so was in Zukunft eben nicht mehr zu gebrauchen ! Was ist eigentlich mit objektorientierter Programmierung ? Goto hat in dieser Welt einfach nichts zu suchen und fertig. Und wenn einer in "hunderttausenden" Programmzeilen nur einmal goto benötigt, dann frage ich mich, warum er alleine aus ästhetischen Gründen dieses nicht auch noch elimininiert.

Vorsichtshalber habe ich jetzt mal mit grep die VCL auf gotos untersucht, ob sich da eventuell ein Hinweis findet, wo sie Sinn machen : ja, das Wort taucht tatsächlich zweimal auf ! In 2 Kommentaren. :mrgreen:

[sakura]

Zitat:

Zitat von omata

folgende Befehle sind überflüssig: exit, goto, break das sind Befehle, die nicht zu einer strukturierten Programmierung gehören.

Hm komisch, break und continue sind recht junge Sprachkonstrukte in Delphi. Glaubst Du wirklich, man hätte die eingeführt, wenn die nicht dazu gehören. Ich weiß nicht mehr wann die kamen, aber es war "gegen" Delphi 3, so circa ;)

...:cat:...

[Hansa]

Zitat:

Zitat von sakura

..Hm komisch, break und continue sind recht junge Sprachkonstrukte in Delphi.

Auch das stimmt und ist der Grund dafür, daß so was in meinen Programmen mal nicht zu finden ist. Daraus könnte man ja auch den Umkehrschluß ziehen, daß man es eben nicht braucht. Ich sage mal, es ist ein neueres Zugeständnis an die Delphi-Verwandschaft, insbesondere für Schreibfaule, siehe Luckie. :mrgreen: Der mögliche Schaden ist durchaus begrenzt und ein erfahrener Programmierer kommt locker damit klar. Schließlich geht es da nur um eine einzelne Spaghetti, die vielleicht nicht genau in der Mitte geteilt wurde, was allerdings geplant war. Gotos sind dafür verantwortlich eine größere Menge Spaghetti-Code zu produzieren, wo man wirklich nicht mehr sagen kann wo Anfang und Ende einer Nudel genau ist. :cat: Wo ist Alzaimer ? Der kennt sich damit aus.

[Luckie]

Zitat:

Zitat von Hansa

Mit einem Goto springe ich notfalls mitten in einen uninitialisierten Prozess.

Nein, mit einem Goto kan man auch nicht prozedurübergreifend springen.

Zitat:

Der war/ist bestimmt auf Uni. Da lernt man, solche Sachen am Besten nicht zu benutzen.

Auf der Uni lernt man auch vieles, was mit der Realität nicht viel genmein hat.

Zitat:

Jetzt kommen nooch einige und sagen : goto gehört zum Sprachumfang, warum soll ich es denn dann nicht benutzen ? Ganz einfach, sofern man weiß, warum das überhaupt in Pascal drin ist : es ist lediglich ein Zugeständnis an Umsteiger, hauptsächlich von Basic her. 1972 hat Wirth die ersten Studenten an Pascal drangelassen. Die mußten dann lernen, wie sie die Gotos aus ihren Basic Programmen eliminieren, um so was in Zukunft eben nicht mehr zu gebrauchen ! Was ist eigentlich mit objektorientierter Programmierung ? Goto hat in dieser Welt einfach nichts zu suchen und fertig. Und wenn einer in "hunderttausenden" Programmzeilen nur einmal goto benötigt, dann frage ich mich, warum er alleine aus ästhetischen Gründen dieses nicht auch noch elimininiert.

Schöne Begründung. Aber wie Neotracer64 schon gesagt hat, es gibt Gründe es zu benutzen:

Zitat:

Benutze "goto, break, exit" dann, wenn es die Wartbarkeit/Übersichtlichkeit begünstigt und sonst einfach nicht. Je nachdem wie es besser passt.

[Luckie]

Zitat:

Zitat von omata

und nunmal ohne exit...

Code:

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';

if fehler = '' then
  // mache was, es ist alles ok
Result:=fehler;

Das geht nicht. Wenn ich keine Belegnummer habe, kann ich kein Belegdatum ermitteln. Sprich, wenn ich die Belegnummer nicht habe, kann ich nicht weiter machen. Nächster Vorschlag bitte.

[Daniel]

Zitat:

Zitat von Hansa

Mann mann, sogar mit Moderatorenhilfe werden Argumente gegen eine strukturierte Programmierung gesammelt. Ich glaub ich bin im falschen Film. :shock:

Den Eindruck habe ich allerdings auch.
Es ist zu unterscheiden, ob Michael in seiner Rolle als Moderator etwas zu diesem Thema schreibt oder in seiner Rolle als Delphi-Entwickler.


Aber diese gesamte Diskussion ist hinfällig. Es geht um wartbaren Code und niemand konnte bisher darlegen, dass ein exit quasi per se schlechten Code erzeugt. Alles, was man hier als Negativbeispiel liest, sind grausige Anwendungsfälle von Sprungbefehlen - aber mal ehrlich: Grausame Sachen kann ich auch mit Variablen oder gar Klassen realisieren, ganz in der vermeintlich hübsch strukturierten Welt.

Guter Code entsteht nicht automatisch durch den Verzicht von Sprungbefehlen und auch umgekehrt wird guter Code nicht zwingend zu schlechtem Code, wenn man dort ein wohlplatziertes "exit" findet.

[Ultimator]

Zitat:

Zitat von Hansa

Was ist eigentlich mit objektorientierter Programmierung ?

Mann mann, was hat denn jetzt objektorientierte Programmierung mit der Verwendung von goto zu tun? :roll:
Ich kann auch in meinen Objektmethoden ein goto verwenden.
Um den ganzen Aufstand um die "an den Haaren herbeigezogenen Codebeispiele" mal zu beruhigen: Ist es denn so schwer, einfach mal zuzugeben, dass ein goto in manchen Fällen wirklich sinvoll ist? Aber nein, man muss (wie es z.B. bei Luckies Code war) mit aller Gewalt versuchen, die gotos aus dem Code zu eliminieren, wobei man ihn auf die etwa eineinhalbfache Länge streckt und dabei noch verkompliziert.

[Jasocul]

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;

Ob der Code nun besser oder schlechter ist, sei mal dahingestellt.
Man kann alles ohne Goto lösen und ich mache das auch. Mit richtigen Einrückungen sehe ich auch sofort, wo ich weiter lesen muss, wenn eine Bedingung nicht erfüllt ist. Sowas kann ich nicht als Argument für Goto gelten lassen.
Bisher hatte ich noch keine Verwendung für ein Goto. In Basic habe ich auch schon programmiert. Dort habe ich es allerdings verwendet.
Break habe ich auch schon verwendet, allerdings muss ich schon sehr übrelegen, wann es das letzte mal war. Continue habe ich genau einmal verwendet, weil ich für eine Testprozedur einfach zu faul war, die Schleife umzustellen. Das einzige, was ich gelegentlich mal verwende, ist exit. Immer dann, wenn ich in einer Testphase gewisse Bereiche im Source aussparen möchte.
Wer so starke Verschachtelungen hat, dass es nicht mehr überschaubar ist, sollte sich über die Nutzung von Funktionen mal Gedanken machen.

Ich benötige bisher kein goto. Wer es nutzen will, soll es machen. Allerdings sollte man sich bei einer Team-Programmierung (oder wenn andere den Source bearbeiten müssen) sehr genau überlegen, wie intensiv das Goto genutzt wird. Sollte ich irgendwann die Notwendigkeit sehen, dass ich es nutzen muss, werde ich es auch machen. Aber ich werde es vermeiden, wenn sinnvoll möglich.

[richard_boderich]

selbst unter basic hab ich vieles mit GOSUB und RETURN erledigt und auf ein goto verzichten koennen.
ich hab in meiner ganzen delphi zeit nich ein goto verwendet. nur einmal bei nem alten turbo pascal programm. und auch nur weil es nicht anders ging (geschachtelte schleife verlassen)

die aussage ueber positive logic halte ich fuer unsinnig. wenn sich die gleiche programmfunktion mit weniger code bzw. lesbarerem code realisierbar ist, verwende ich durchaus auch negative logic
vom code her gesehn gebe ich luckies variante eindeutig den vorzug. aber ist nur meine persoenliche meinung. soll jeder machen wie erst fuer richtig haelt.

richard

[Der_Unwissende]

Hi Leute,
ihr seit echt mega OT. Als jmd. der mal gerade alle Beiträge gelesen hat, möchte ich sagen ihr dreht euch schon etwas im Kreis.
Fazit bisher, es gibt Sprungbefehle verschiedener Art und alle können benutzt werden oder nicht.
Es lässt sich doch hier eh keiner bekehren, ob ihr jetzt noch so pseudo-sachlich kommentiert oder nicht.

Egal wie man programmiert, an dem bedingten Sprung kommt doch letztlich der Assembler gar nicht vorbei. Wie schön wäre es denn für die CPUs, wenn es nie zu einem Sprung käme, dass ne Menge Geld in die Vorhersagbarkeit fließt spricht mindestens auf der Ebene für das goto. Und somit wird schon jede Sprache die inline Assembler unterstützt nicht ums goto rum kommen.
Wie jedes Sprachfeature bleibt es aber dem Programmierer überlassen es zu verwenden. Ob man dies übersichtlich an wenigen o der unübersichtlich an vielen Stellen macht hat doch nichts mit dem Befehl an sich zu tun.
An dieser Stelle sei auch erwähnt, dass nicht alle C Programme in einer Zeile stehen, nur weil es Menschen gibt die solche Programme erstellen.

Der Satz, dass einem an der Uni gesagt wird man darf ein goto nicht verwenden (oder sollte es meiden) ist auch sehr sehr weit hergeholt. Wer soll einem dass den sagen? Ich meine du hast da sicherlich nicht den Kurs "Programmieren allgemein und in allen Sprachen". Es gibt wie gesagt Sprachen, da kommt man gar nicht um ein Label mit Sprung rum, da es keine Alternativen gibt. Zudem möchte die Uni (zumindest keine die ich kenne) einen nicht eine spezielle Sprache lehren. An der Freien Universität Berlin sind im Moment Veranstalltungen in Haskell, Java (J2SE und J2EE), C, C# und Prolog am laufen (das sind die von denen ich weiß). Was jetzt also noch an weiteren Sprachen dort gelehrt wird, wer weiß. Da die Studenten all diese Kurse früher oder Später besuchen könnten nutzt ihnen die Kenntnis einer Sprache einfach nichts. Hat man die Grundlagen hingegen verstanden, ist der Rest nur noch Syntax. Deshalb wird an Universitäten sehr abstrakt gelehrt, da kann also keiner Sprachbezogen von einem Sprung abraten (wie gesagt ist man nur maschinennah genug geht das gar nicht anders).

Gruß Der Unwissende

[mkinzler]

Jetzt fehlt nur noch die obligatorische Umfrage-Option anderer Foren. Dann können sich hier 2 Gruppen bilden, die nicht mehr miteinander Reden, bis eine Seite zugibt sich geirrt zu haben. ;-)

[OregonGhost]

Zitat:

folgende Befehle sind überflüssig: exit, goto, break das sind Befehle, die nicht zu einer strukturierten Programmierung gehören. Das ist nun mal so. da kommt man nicht drum herum. Natürlich kann man alles irgendwie hinwurschteln. Aber warum? warum nicht gleich ordentlich und strukturiert programmieren?

An der FH hat ein Professor mir beigebracht, dass und warum man immer strukturiert programmieren soll. Er hat der Vollständigkeit halber die entsprechenden C-Sprachkonstrukte erklärt (also return, goto, break, continue), aber auch, dass man sie niemals benutzen darf, außer natürlich im switch (in C# ist das break dort ein Teil der Syntax und kein echter Sprungbefehl).
Aber das ganze hatte einen Hintergedanken - man sollte die Programme nicht nur als Code, sondern auch als Struktogramm zeichnen können. Habt ihr das mal gemacht? Eine der unsinnigsten Erfindungen, die es gibt, in meinen Augen. Genauso sinnlos wie zigfach verschachtelte Ifs und Thens zu verwenden, anstatt sie zu umgehen. Sobald man nämlich eine Exception (das ist doch ein Feature moderner Sprachen? :P) verwendet, ist nix mehr mit strukturiert im klassischen Sinne. Dann springt man nämlich sofort raus. Sogar noch brutaler als mit einem break oder goto. Man weiß innen nämlich nichtmal, wo man landet, denn vielleicht fängt die aufrufende Methode die Exception ab, vielleicht wird sie auch über zig Ebenen nach oben gereicht.
Also, Exceptions benutzt man, aber goto nicht, und nichtmal break oder continue?
Fahrt ihr auch nicht in PKWs mit, weil man damit Menschen umfahren kann, aber in Bussen schon?

Die Tatsache, dass man mit einem Sprachkonstrukt (einer Klasse aus eine Laufzeitbibliothek, einem Programm...) immensen Schaden anrichten kann, als Vorwand zu nehmen, das Konstrukt niemals zu verwenden, ist ideologisch vielleicht sinnvoll, praktisch aber unsinnig. Darf ich niemals einen Treiber schreiben, nur weil ich mit einem Treiber Windows XP zu einem Bluescreen bringen könnte?

Ach, und noch eine Ergänzung zum Thema OOP. Schonmal gemacht? Code bleibt Code, egal ob ich in einer Methode bin und meine Variablen alle Objekte sind statt fundamental. Es sind immer noch Funktionsaufrufe, immer noch Ifs und Thens und Schleifen, und immer noch Sprungbefehle. Insofern macht es für diese Diskussion keinen Unterschied, ob man objektorientiert oder prozedural programmiert.
Hmm, und dann noch, man soll das Zeug nicht verwenden, weil es so jung ist Oo
Iteratoren, Generics und Nullable Types gibt es in C# erst ab der Version 2.0 - darf ich sie jetzt nicht verwenden? War ja ursprünglich nicht vorgesehen...

[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;

@luckie

Da wird der Code auch nur ausgeführt, wenn kein Fehler auftritt. Beim ersten Fehler verlässt er die weiteren Vergleiche. Ist vielleicht mehr Tipparbeit, aber bei weitem übersichtlicher als innerhalb von 15 ifs mit Exit zu antworten.

[DIET3RIX]

Zitat:

Zitat von OregonGhost

Aber das ganze hatte einen Hintergedanken - man sollte die Programme nicht nur als Code, sondern auch als Struktogramm zeichnen können. Habt ihr das mal gemacht? Eine der unsinnigsten Erfindungen, die es gibt, in meinen Augen.

Genauso seh' ich das auch, so wurde mir das auch auch ma beigebracht.

[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 :lol: ) die ich in den bisherigen 2 Studien-Semestern hoeren musste :roll:

[Der_Unwissende]

Zitat:

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:

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 :roll:

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:

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:

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? :shock:
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. :mrgreen:

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

[Michael Habbe]

Zitat:

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:

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:

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. :gruebel:
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??? :-D

Beste Grüße an die DP!

[mkinzler]

Nein, aber wenn du uns sagst, wo du wohnst ... :-D

[Peinhard]

Zitat:

Zitat von mkinzler

Eine Forschleife sollte man auch nicht abbrechen müssen, sonst würde ich halt ne while-Schleife nehmen mit den 2 Bedingungen.

Naja, die VCL ist jedenfalls voll davon:

Delphi-Quellcode:

function TFields.FindField(const FieldName: string): TField;
var
  I: Integer;
begin
  for I := 0 to FList.Count - 1 do
  begin
    Result := FList.Items[I];
    if AnsiCompareText(Result.FFieldName, FieldName) = 0 then Exit;
  end;
  Result := nil;
end;

um nur ein Beispiel von vielen zu nehmen...

[alcaeus]

:shock: Sowas:

Delphi-Quellcode:

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

geht auch so:

Delphi-Quellcode:

Daten := '';
repeat
  readln(f, Daten);
until EOF(f) or (Daten <> '');

Greetz
alcaeus

[Go2EITS]

@MKinzler
Du weichst vom Thema ab MKinzler! (ERMAHN!) :-D

Meine Lösung scheint wohl OK zu sein. In Assembler gibt es ja auch Sprünge in dieser
Art. Und ein EXIT, wenn in der Funktion das Result natürlich gesetzt wurde, bevor nochmals
viele IF's abgearbeitet werden müssen verwende ich auch. In einer Procedure ebenso, wenn
das Ergebnis erziehlt wurde. Ich setze GOTO und EXIT dann ein, um den Code nicht zu komplizieren.
Break setze ich ungern ein. Geschmackssache eben, aber bevor ich eine umfangreiche Schleife mit
100.000 Durchläufen in den ersten 1000 Durchläufen beenden kann, könnte BREAK helfen. Manchmal ist es der Performance behilflich.

@alcaeus
Gute Lösung.
Ich habe aber nicht nur ein Daten:="" sondern auch:
...lesen der Daten aus File

Delphi-Quellcode:

Daten:=Trim(daten);
if daten[1]:='/' then goto Start;
if Daten[1]:='#'then goto Start;
if pos('C:\',daten) >0 then goto Start;

[edit]
Und hier stehen noch weiter Codes zum Verarbeiten des DATEN Strings,
zum Beispiel
showmessage('Daten: ',DATEN);
etc...
etc..

Und das soll ich in
until EOF(f) or (Daten <> '').... packen?

Ich mag es nicht so. Und meinen Fehler habe ich gesehen: if EOF(f) und nicht not EOF(f). Korrigiert, damit jemand es nicht falsch nachahmt. Und es stellt sich die Frage, was wirklich schneller ist.
(Wahrscheinlich keines von beiden, weil der Compilercode wohl gleich ist.)

[edit=alcaeus]Delphi-Tags eingefuegt ;) Mfg, alcaeus[/edit]

[mkinzler]

Ich hatte deinen Code als Witz aufgefasst, du meinst das also ernst? :o

Zitat:

in Assembler gibt es ja auch Sprünge in dieser Art.

Da der Prozessor keine strukturierten Elemente kennt.

Zitat:

Ich setze GOTO und EXIT dann ein, um den Code nicht zu komplizieren.

Wenn du ihn so einsetzt, wie in deinem Beispiel schon.

BTW: Ein funktionierender Code ist noch lang kein guter Code.

[Go2EITS]

@MKinzler
War ernst... :oops: Beispiel oben um realen Einsatz geändert.
Sollte ich vielleicht CASE nehmen?

[mkinzler]

Dann solltest du dir norchmal die Grundlagen strukturierter Programmierung reinziehen.

[Edit]

Zitat:

Sollte ich vielleicht CASE nehmen?

Nein While oder Repeat; siehe auch Beitrag 72 von alcaeus [/edit]

[Go2EITS]

@MKinzler
:warn:

Ne, Spass beiseite.
Also, nun muss ich es wohl doch mit GOTO lösen:

Delphi-Quellcode:

Result:=False;
Daten:='';
repeat 
readln(f, Daten);
Daten:=Trim(daten); 
if Daten:=chr(13)+Chr(10) then goto ENDE; // LF 
if Daten:='' then goto ENDE;              //Leerraum
if daten[1]:='/' then goto ENDE;          //Kommentarzeile
Daten[1]:='#'then goto ENDE;              //Kommentarzeile
pos('C:\',daten) >0 then goto ENDE;       //Rootverzeichnis
//Und hier stehen noch weitere Codes zum Verarbeiten des DATEN Strings 
showmessage(Daten);                       //Zum debuggen
If pos('DEBUG',DATEN) >0 then             //Die erste Verarbeitung...
   begin
   RESULT:=TRUE; //Wir haben ja etwas gültiges gefunden...   
   //CODE hier 
   end;
// Hier stehen nochmals einige IF mit entsprechender Verarbeitung 

ENDE:  
until EOF(f);

Muss ich nochmal die Grundlagen strukturierter Datenverarbeitung lesen?
Verbessere bitte meinen Code. Wie kann ich es eleganter machen?
Ich lerne gerne dazu, bzw. verbessere meinen Programmierstil (Ernst gemeint!)
Und statt IF's CASE zu nehmen dürfte das "GOTO-Problem" auch nicht lösen.

[sakura]

:shock:

Bei ReadLn wird die Bedingung Daten = chr(13)+Chr(10) nie auftreten, da der Zeilenumbruch nicht zurück geliefert wird, sondern nur ein leerer String. Aber mal zum Wesentlichen:

Delphi-Quellcode:

Result := False;
repeat 
  readln(f, Daten);
  Daten := Trim(daten); 
  if Daten <> '' then
    if not (Daten[1] in ['/', '#']) then
      if Pos('C:\', Daten) = 0 then
      begin
        showmessage(Daten);                       //Zum debuggen
        If pos('DEBUG',DATEN) >0 then             //Die erste Verarbeitung...
        begin
          RESULT:=TRUE; //Wir haben ja etwas gültiges gefunden...   
         //CODE hier 
        end;
      end;
until EOF(f);

Zitat:

Muss ich nochmal die Grundlagen strukturierter Datenverarbeitung lesen?

Ja :shock:

...:cat:...

[Michael Habbe]

Zitat:

Zitat von Go2EITS

Muss ich nochmal die Grundlagen strukturierter Datenverarbeitung lesen?
Verbessere bitte meinen Code. Wie kann ich es eleganter machen?
Ich lerne gerne dazu, bzw. verbessere meinen Programmierstil (Ernst gemeint!)
Und statt IF's CASE zu nehmen dürfte das "GOTO-Problem" auch nicht lösen.

Hallo, ich habe ihn mal überarbeitet. Du solltest gleiche Elemente zusammenfassen (hier mit or geschehen). Die Performance leidet nicht darunter, weil, wenn die erste Bedingung erfüllt wird, werden die anderen nicht mehr überprüft.

Delphi-Quellcode:

Result:=False;
Daten:='';
repeat
  readln(f, Daten);
  Daten:=Trim(daten);
  if (Daten=chr(13)+Chr(10)) or
     (Daten='') or
     (daten[1]='/') or
     (Daten[1]='#') or
     (pos('C:\',daten) >0) then
  begin
    // tue hier irgendwas
    // wenn nichts geschehen soll, lass diese Stelle
    // einfach leer, vielleicht brauchst Du es später
    // so wird gleich ersichtlich, dass nichts 
    // geschehen soll, wenn diese Bedingung erfüllt ist
  end
  else
  begin
    //Und hier stehen noch weitere Codes zum Verarbeiten des DATEN Strings
    showmessage(Daten);
    If pos('DEBUG',DATEN) >0 then
    begin
      RESULT:=TRUE; //Wir haben ja etwas gültiges gefunden...
      //CODE hier
    end;
    // Hier stehen nochmals einige IF mit entsprechender Verarbeitung
  end;
until EOF(f);

[himitsu]

Zitat:

Zitat von Go2EITS

Delphi-Quellcode:

Result:=False;
Daten:='';
repeat 
readln(f, Daten);
Daten:=Trim(daten); 
if Daten:=chr(13)+Chr(10) then goto ENDE; // LF 
if Daten:='' then goto ENDE;              //Leerraum
if daten[1]:='/' then goto ENDE;          //Kommentarzeile
Daten[1]:='#'then goto ENDE;              //Kommentarzeile
pos('C:\',daten) >0 then goto ENDE;       //Rootverzeichnis
//Und hier stehen noch weitere Codes zum Verarbeiten des DATEN Strings 
showmessage(Daten);                       //Zum debuggen
If pos('DEBUG',DATEN) >0 then             //Die erste Verarbeitung...
   begin
   RESULT:=TRUE; //Wir haben ja etwas gültiges gefunden...   
   //CODE hier 
   end;
// Hier stehen nochmals einige IF mit entsprechender Verarbeitung 

ENDE:  
until EOF(f);

Und statt IF's CASE zu nehmen dürfte das "GOTO-Problem" auch nicht lösen.

Und der Code läuft?

Bei den fehlen IFs und den := für Vegleiche kann ich es mir ja nicht so vorstellen :roll:

CASE für die IFs wäre eh nicht möglich, da CASE in Delphi nur mit Ordinalen Typen klarkommt und denmach für die Auswerdung von Strings vollkommen (ohne Hilfsmittel zur Konvertierung) ungeeignet ist.