Entwickler-Ecke
Delphi Language (Object-Pascal) / CLX - Problem mit ends
henny - Di 30.06.09 13:45
Titel: Problem mit ends
Hallo ich habe ein Programm geschrieben das eine Methode hat mit 1000 zeilen und wo oft "begin" drin ist.
Am ende muss ich dann umgefähr 200 mal "end" schreiben
Kann man das irgendwie umgehen wie z.B. end*50 oder so?
Gausi - Di 30.06.09 13:48
Ja. Zerlege diese Monster-Methode in mehrere kleinere. Wenn das nicht direkt geht, überdenke dein Konzept.
jasocul - Di 30.06.09 16:15
1. Ein "end" hinschreiben.
2. Die Zeile markieren, kopieren und einfügen.
3. Jetzt die 2 Zeilen markieren, kopieren und einfügen.
4. Jetzt die 4 Zeilen markieren, kopieren und einfügen.
5. Jetzt die 8 Zeilen markieren, kopieren und einfügen.
6. Jetzt die 16 Zeilen markieren, kopieren und einfügen.
7. Jetzt noch 18 Zeilen markieren, kopieren und einfügen.
Wenn ich mich jetzt nicht irre, hat man dann 50 Zeilen mit "end".
Ich bezweifle allerdings, dass das sinnvoll ist. Du solltest Deinen Source wirklich überarbeiten, wie meine Vor-Poster schon geschrieben haben.
ffgorcky - Di 30.06.09 17:49
Zu Deinem Vorschlag
jasocul:
Das fände ich einfacher, wenn Du einfach nur einmal ein
(auch gerne mit Zeilenumbruch dahinter, den man hier jetzt leider nicht sehen kann) reinschreibst,
dieses markierst und dann einfach nur einmal Strg+C, und danach einfach länger Strg+V gedrückt hältst.
Regan - Di 30.06.09 20:34
Wie wäre es mit Makros?
jaenicke - Di 30.06.09 20:53
Was bringt es denn irgendwie das Kopieren zu vereinfachen? Ich meine wie schon gesagt wurde ist das Konzept so mehr als ungünstig. Richtig durchdacht und dann klappt das auch...
Popov - Di 30.06.09 21:46
henny hat folgendes geschrieben : |
Hallo ich habe ein Programm geschrieben das eine Methode hat mit 1000 zeilen und wo oft "begin" drin ist.
Am ende muss ich dann umgefähr 200 mal "end" schreiben
Kann man das irgendwie umgehen wie z.B. end*50 oder so? |
Ein echter Programmierer hätte schon längst ein Programm geschrieben das ihm 50 mal end erzeugt.
Ach, ich will nicht so sein:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9:
| procedure TForm1.Button1Click(Sender: TObject); var i: Integer; begin Memo1.Clear;
for i := 1 to 50 do Memo1.Lines.Add(' end;'); end; |
In USA könnte ich mir das sogar patentieren lassen.
Yogu - Di 30.06.09 21:49
Rückst du deinen Code eigentlich ein? Das bezweifle ich stark - nein, das kann gar nicht sein. Wenn du in deiner Prozedur am Ende 50 ends stehen hast, müsstest du - je nach Einstellung - um 100-200 Zeichen eingerückt haben. Das wäre sogar auf einem großen Breitbildschirm im Vollbildmodus mehr als die Hälfte der Fensters ;)
Jetzt mal im Ernst - das kann doch gar nicht funktionieren, oder tut es das?
R4id - Di 30.06.09 21:50
Was macht den überhaupt eine Funktion mit 1000 Zeilen? Die längste Methode die ich geschrieben habe war für TeamSpeak 2 eine Viewer-Methode mit 780 Zeilen perfektem Code :shock:
Popov - Di 30.06.09 22:21
Yogu hat folgendes geschrieben : |
| Jetzt mal im Ernst - das kann doch gar nicht funktionieren, oder tut es das? |
Doch, gehen würde es schon und es wäre auch nicht sonderlich schwer. Aber etwas mehr arbeit als oben wäre es schon.
Ganz einfach: Code in ein Memo kopieren und das Memo von hinten nach vorne durchgegehen. Im ersten Durchgang alle Zeilen ohne begin löschen, im zweiten begins und ends zählen und die geschlossenen begins entfernen, in dritten begins gegen ends tauschen (in umgekehrter Reihenfolge). Aufwand etwa 10 Minuten. Aber in der Zeit kriegt man auch alle ends von hand geschlossen.
Aber ein Tipp fürs Leben: immer sofort das end nach begin schrieben. Ich hab schon seit Jahren keinen offenes begin geschrieben. Dann weiß man auch, daß alles geschlossen ist.
Und für die Faulen: unter Programmierthilfe begin und end eintragen. Dann reichte es begin zu tippen, dann Strg+J und schon ist end da.
Yogu - Mi 01.07.09 15:12
Popov hat folgendes geschrieben : |
Yogu hat folgendes geschrieben : | | Jetzt mal im Ernst - das kann doch gar nicht funktionieren, oder tut es das? |
Doch, gehen würde es schon und es wäre auch nicht sonderlich schwer. Aber etwas mehr arbeit als oben wäre es schon. |
Ich meinte nicht, dass es schwer ist, 50
ends einzufügen, sondern dass sein Programm nicht funktionieren kann. Kein Mensch kann in einer 1000-Zeilen-Prozedur den Überblick behalten.
Hast du den Code wirklich am Stück runtergetippt, ohne einmal zu compilieren und zu testen? Denn dann hättest du ja Schritt für Schritt immer wieder mal ein paar
ends einfügen müssen.
Btw: Hast du Lust, die Methode mal hier zu posten? Würde mich schon interessieren...
jasocul - Do 02.07.09 09:00
Yogu hat folgendes geschrieben : |
| sondern dass sein Programm nicht funktionieren kann. Kein Mensch kann in einer 1000-Zeilen-Prozedur den Überblick behalten. |
So ein Blödsinn. Man kann auch Spaghetti-Code strukturiert programmieren. Ich habe derartigen Source schon gesehen und problemlos nachvollziehen können. Aber vielleicht bin ich ja kein Mensch. :twisted:
Der Code muss funktionieren. Im Überblick muss man den nicht behalten, wenn er einmal läuft.
Empfehlenswert ist das allerdings nicht.
BenBE - Do 02.07.09 10:28
Wozu gibt's Code-Folding :P
Und um ehrlich zu sein: Ich hatte schon eine knapp 10kLOC-Prozedur und hab mich dort drin orientieren können. Da Spaghetties aber gegessen und nicht zu Code verarbeitet gehören ist das ja nahezu das schlimmste mögliche Fastfood-Verbrechen ;-) Abgesehen von unserem Rezeptvorschlag an Subway
jaenicke - Do 02.07.09 10:32
Ich hatte auch schon relativ lange Methoden (wenn auch eher bis vor ein paar Jahren, heute nicht mehr wirklich), aber ich hatte dort nie 50 ends hintereinander oder so.
Aber warten wir doch einfach einmal, ob
henny selbst überhaupt noch etwas dazu sagt... ;-)
delfiphan - Do 02.07.09 11:13
@henny: Kannst du mal den Code posten oder uns mitteilen, wie die grobe Struktur aussieht? Z.B. so: (?)
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| if ... then begin end else begin if ... then begin end else begin if ... then begin end else begin end end end |
Popov - Do 02.07.09 21:04
Ach was, in der C64 Zeit konnte man noch jeden Code nachvollziehen und hatte vor Spagetti keine Angst.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28:
| procedure TForm1.Button1Click(Sender: TObject); var i: Integer; s: String; label Anfang, Ende, Start, Weiter, iCountLoeschen, AllesLoeschen, Anzeigen, Zaehlen; begin Goto Anfang; Start: if Memo1.Lines.Count > 0 then Goto AllesLoeschen; Weiter: if i <> 0 then Goto iCountLoeschen; Zaehlen: for i := i to (i + 1) * 10 do s := s + IntToStr(i); goto Anzeigen; Anfang: if Memo1.Lines.Text <> '' then Goto Start; iCountLoeschen: i := 0; goto Zaehlen; Anzeigen: ShowMessage(s); goto Ende; AllesLoeschen:
Goto Weiter; Ende: end; |
Moderiert von
Christian S.: Code- durch Delphi-Tags ersetzt
jaenicke - Do 02.07.09 21:07
Naja, bis man den Code verstanden hat, dauerts aber 20 mal so lange wie wenn er ordentlich geschrieben wäre. :lol:
Nachvollziehen kann man jeden Code, die Frage ist immer nur wie schnell. Arbeitszeit usw.
Blackheart666 - Do 02.07.09 22:38
Mittlerweile weiss man doch das Henny etwas schreibfaul ist bei der Problembeschreibung wie auch bei Beantwortungen dazu.
Wie schon des öfteren gesagt Grundlagen sind alles - Crashkurs - den Link erspare ich mir, schon zwanzig mal angefügt. :wink:
Reinhard Kern - Fr 03.07.09 00:26
Hallo,
was ich mir da oft erlaube, ohne zu behaupten, das sei ordentlicher Stil:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| if FileExists (..) then begin if FileIsOpen (..) then begin if Assigned (..) then begin end; end; end;
if not FileExists (..) then exit; if not FileIsOpen (..) then exit; if not Assigned (..) then exit; |
Ich finde (nur ich persönlich! Angriffe zwecklos!) der Anfang einer Prozedur ist so absolut übersichtlich und ich spare mir die begin-end-Orgien.
Es gibt aber Richtlinien, die das verbieten: z.B. dass es für eine Prozedur nur einen Eintritts- und einen Austrittspunkt geben darf. Für umfangreiche Projekte und streng strukturierte Grossfirmen hat das seine Berechtigung.
Gruss Reinhard
Popov - Fr 03.07.09 01:02
Reinhard Kern hat folgendes geschrieben : |
Delphi-Quelltext 1: 2: 3: 4:
| if not FileExists (..) then exit; if not FileIsOpen (..) then exit; if not Assigned (..) then exit; | |
In dem einen Fall ist es ja ok, aber schreib mal das:
Delphi-Quelltext
1: 2: 3: 4:
| if not FileExists (..) then if not FileIsOpen (..) then exit else (..); |
Auch wenn man das Problem hier vielleicht nicht sofort erkennt und das Beispiel nicht besonders ist (auf die Schnelle fällt mir nicht besseres ein), aber wie leicht hat man bei verschachtelten ifs andere Ergebnisse als man dachte.
jaenicke - Fr 03.07.09 01:09
Dafür gibt es ja CnWizards oder andere (meist kommerzielle) Tools, die diese Fehler sofort sichtbar machen.
Zumindest, wenn man es ordentlich (und in dem Fall falsch) einrückt.
Und zudem automatische Codeformatter, die das auch sofort aufdecken.
Beides unter der Voraussetzung, dass man mit den Ergebnissen auch etwas anfangen kann. :mrgreen:
Reinhard Kern - Fr 03.07.09 02:23
Popov hat folgendes geschrieben : |
In dem einen Fall ist es ja ok, aber schreib mal das:
Delphi-Quelltext 1: 2: 3: 4:
| if not FileExists (..) then if not FileIsOpen (..) then exit else (..); |
... |
Hallo,
wahrscheinlich ist es schon zu spät in der Nacht, aber vielleicht hilfst du mir auf die Sprünge (schreckliches Wort um die Uhrzeit) - ich komme nicht drauf, wann ein else nach einem exit sinnvoll ist. Nach einem "if Abbruchbedingung then exit" ist doch alles weitere sowieso der Else-Zweig?
Übrigens gerade wegen der Übersicht verschachtele ich die Ifs eben nicht, im Gegensatz zur Lehrmeinung. Meine bevorzugte Struktur ist
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| if Abbruchbedingung1 then exit; if Abbruchbedingung2 then exit; if Abbruchbedingung3 then exit; if Abbruchbedingung4 then begin Closefile; File.Delete; exit; end; |
Ist praktiziertes KISS-Prinzip.
Gruss Reinhard
exit;
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!