Entwickler-Ecke
Off Topic - Warnings ausmerzen?? sinnvoll?
Delphianer23 - Mi 19.02.03 20:28
Titel: Warnings ausmerzen?? sinnvoll?
[Warning] Unit1.pas(723): Variable 'b' might not have been initialized
[Warning] Unit1.pas(867): Variable 'speich' might not have been initialized
solche warnings kennt wohl jeder, die nerfen mich einfach.
Ist ist bei meinen Prog zu 100% gesichert, dass die Datei, wenn sie benutzt wird vorher initi. wird. Soll ich sie wirklich einfach so (nutzlos) vorher inizialisieren, damit die warning nicht mehr erscheint?
(Warnings machen nen schlechten Eindruck)
Moderiert von
Tino: Absätze entfernt.
Christian S. - Mi 19.02.03 20:38
Das kommt auf den Einzelfall an:
wenn Du beispielsweise eine Integervariable in einer FOR-DO-Schleife verwendest, musst Du sie natürlich nicht initialisieren. Aber in vielen Fällen ist ganz einfach sicherer oder notwendig, das zu tun.
Und es sollte immer gelten: besser einmal zu viel initialisiert als einmal zu wenig.
MfG,
Peter
smiegel - Mi 19.02.03 20:47
Hallo,
wenn der Compiler das anmault, dann hat es schon einen Sinn. Dies kommt vor allem dann vor, wenn die Variablen in if- oder case-Bedingungen benutzt werden. Dies soll darauf hindeuten, dass eine Bedingung eintreten kann, bei der die Variable u.U. keinen Wert besitzt. In den meisten Fällen erkennt man dann auch warum.
Die andere Seite ist ja die, wenn man eine überflüssige Zuweisung macht, dass der Compiler auch dies bemängelt.
Delphianer23 - Mi 19.02.03 20:54
in meinenm fall ist es nur so , wenn die Variable verwendet wird wird sie "besetzt" mit einer bestimmten Sache. und dann gehts weiter. Da das ganze aber in ner if schleife zusammenhängt, gibt der die warning raus. Es ist also zu 100% sicher, dass die Variable, wenn sie VERWENDET wird im gleichen "Strang " auch "besetzt" wird.
Es sträubt sich also in mir unnütz Resourcen zu verbrauchen, obwohl diese so gering sind. Delphi macht da nen Fehler, es müsste prüfen, ob die Variable nur dann verwendet wird, wenn sie auch inizilisiert wird. (Natürlich nur bei lokalen Variablen und keinen Rückgabewerten, da das andere für den Programmier sowieso zu unübsichtlich ist und man lieber inizili.) inizielisiert)
Moderiert von
Tino: Absätze entfernt.
hansa - Mi 19.02.03 21:49
Hi,
Zitat: |
Es ist also zu 100% sicher, dass die Variable, wenn sie VERWENDET wird im gleichen "Strang " auch "besetzt" wird. |
Diese Aussage ist der klassische Fall für einen "Bug". Genau so entstehen die.
NICHTS ist 100 % sicher. Was ist denn, wenn Deine Schleife etwas verschoben wird, z.B. durch eine nachträgliche Abfrage ? Dann krachts nämlich, wenn Du trotzdem später noch auf einen dann vielleicht uninitialisierten Wert zugreifst. Das wird dann allerdings tatsächlich irgendwann mal 100%ig passieren. 8) "Weniger ist mehr" gilt hier nun wirklich nicht.
Delphianer23 - Mi 19.02.03 22:10
Das setzt natürlich vorraus, dass ich nachträglich was ändere und meinen Code nicht mehr überblicke. Das kann ich mir bei meinen 10 Zeilen halt nicht vorstellen. Ihr habt aber schon recht, vor allem wenn man in Teams arbeitet oder sehr alte Projekte mal wieder verwenden will, sollte man auf die "Änderungssicherheit" bedacht sein.
Für das konkrete Projekt, also die konkrete Version ist dies allerdings nicht so.
Man könnte z.B auch durch "//Achtung, Wert nicht init. Schleifenreihenfolge beachten" kennzeichnen.
Moderiert von
Tino: Absätze entfernt.
Anonymous - Mi 19.02.03 22:36
Ich hab bis jetzt nur ein einziges mal erlebt, daß der Compiler das was ich gemacht habe mißverstanden hat. Früher haben mich diese Hinweise und Warnungen auch nur gestört. Ich war mir sicher, daß ich da keine Fehler gemacht habe. Alles sah immer fehlerlos aus. Irgendwann hab ich mich drangesetzt und, damit der Compiler endlich Ruhe gibt, die Sachen überprüft. Ih hab gemerkt, daß der Compiler schon wuste wieso er die Hinweise ausgegeben hat. Such also lange genug und du wirst die Fehler finden. Ich für meinenTeil habe nichts gegen die Hinweise, denn sie sorgen dafür das ich eventuelle Fehler beseitige.
Of sieht man die Fehler nicht, sie sind aber da:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| function DeleteFile2(FileName: String): Boolean; begin if not FileExists(FileName) then Exit;
Result := DeleteFile(FileName); end;
procedure TForm1.Button1Click(Sender: TObject); begin if DeleteFile2('c:\test.txt') then ShowMessage( 'Gelöscht' ); end; |
Die Message Meldung bei mir sagt übrigens immer "Gelöscht", auch wenn die Datei nicht mehr da ist.
AndyB - Mi 19.02.03 22:46
Popov hat folgendes geschrieben: |
Die Message Meldung bei mir sagt übrigens immer "Gelöscht", auch wenn die Datei nicht mehr da ist. |
Das ist aber reiner Zufall und liegt nur daran, dass True als <> 0 definiert ist. Und die Change das gerade eine 0 an der Stelle, an der Result liegt, steht ist sehr gering, aber nicht unwahrscheinlich.
hansa - Mi 19.02.03 23:05
@Popov : Geht das nicht einfacher so ?
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| function DeleteFile2(FileName: String): Boolean; begin DeleteFile2 := DeleteFile(FileName); end;
procedure TForm1.Button1Click(Sender: TObject); begin if DeleteFile2('c:\test.txt') then ShowMessage( 'Gelöscht' ); end; |
Aber das mit dem Exit und Result ist wieder sowas, wie mit der Initialisierung. Lesbarer wird es dadurch nicht, eher fehleranfälliger. Diese beiden Wörter sind in einem Programm von mir jedenfalls nicht zu finden.
Anonymous - Mi 19.02.03 23:43
Mir ist auch klar, daß man das besser machen könnte. Das war auch nicht der Sinn des Beispiels. Ich wollte nur zeigen, daß man glauben kann, daß das Result eindeutig ist. Bei der zwei Zeilen sieht man das vielleicht noch. Bei 40 Zeilen könnte das schon etwas unübersichtlicher sein. Eine fehlerfreie Funktion in die man vielleich noch mal schnell eine Abfrage mit Exit einbaut. Schon ist Result nicht eindeutig.
Also jetzt nicht auf das Tunig der Funktion konzentrieren. Das Beispiel ist extra so konstuiert. Es soll einen nicht fehlerfreie Funktion sein.
hansa - Do 20.02.03 01:29
jaja, das Beispiel ist ja auch gut so. Wo ich das da lese, fällt mir ein, was ich eigentlich ausdrücken wollte und warum ich auf Exit usw. verzichte. Selbst wenn ich alles richtig initialisiere ist das keine Garantie dafür, daß ein gültiger Rückgabewert drin steht :!: Mit Exit wird die procedure vor deren Ende verlassen. D.h. die wird bis irgendwo ausgeführt und dann eben nicht mehr. Das ist dann so eine Art Ersatz von GOTO in Basic. Früher hatte ich auch gerne Exit benutzt, geht schon einfacher, als noch eine lokale Hilfsvariable zu benutzen, aber dann habe ich gemerkt, daß es viele Fehlerquellen produziert hat. Im Endeffekt schreibe ich lieber eine Zeile mehr Code und verzichte darauf.
Da fällt mir noch folgendes ein : Es gibt Programmiersprachen, bei denen die Initial. aller Variablen zwingend gefordert wird, sonst wird nix compiliert. Glaube ADA gehört dazu. Sehr pascal-ähnlich, nur strenger.
Udontknow - Do 20.02.03 15:25
Hi!
Zitat: |
Selbst wenn ich alles richtig initialisiere ist das keine Garantie dafür, daß ein gültiger Rückgabewert drin steht |
Ich glaube, das solltest du näher erklären... Was ist für dich gültig? Wenn du alles initialisierst (so etwas tut man natürlich
vor dem ersten Exit-Aufruf), wie sollte plötzlich durch Verwendung des Exits ein undefinierter Rückgabewert entstehen?
Ich persönlich benutze Exit sehr häufig, gerade weil es viel übersichtlicher (und daher weniger fehleranfällig) ist als dauernd Abbruchbedingungen in 50 verschachtelten Schleifen einzusetzen.
Ich kann mich Popovs Meinung nur anschliessen: Der Compiler weiss, was er sagt, auch wenn wir es manchmal nicht sofort verstehen. :wink:
Cu, :)
Udontknow
Aya - Do 20.02.03 16:37
Hi,
also manchmal nerven mich diese Meldungen ja auch... zum glück verschwinden die immer wenn man 5-6x auf STRG+F9 drückt :twisted:
Mal nen Beispiel...:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| const Version: 'DEMO';
[...]
procedure CheckVersion; var x: Integer; begin if Version='DEMO' then x:=1 else if Version='FULL' then x:=2 [...] end; |
Das ergibt die Warnung das X nicht initialisiert sein könnte... gut, ich könnte jetzt nen Else reinmachen und so.. aber is halt nur nen beispiel :)
Au'revoir,
Aya
Klabautermann - Do 20.02.03 16:46
Hallo,
um euch ein wenig Hoffnung zu machen: Ab Delphi 7 Kann man Warnungen und Hinweise sowohl generell als auch einzeln abschalten.
Im allgemeinen finde ich diese aber Praktisch. Sie helfen einen Sauberer zu Programmieren.
Gruß
Klabautermann
Aya - Do 20.02.03 16:49
Klabautermann hat folgendes geschrieben: |
Im allgemeinen finde ich diese aber Praktisch. Sie helfen einen Sauberer zu Programmieren. |
Jep, klar...
Aber irgendwie nervts wenn man unten in dem Error-Fenster immer erst runter/hoch scrollen muß, bis man zu den wichtigen fehlermeldungen kommt *g*
AndyB - Do 20.02.03 18:37
Dann musst du eben dafür sorgen, dass keine Warnungen auftreten, so wie es in all meinen Projekten der Fall ist.
In einer Newsgroup zu Delphi hat mal einer gefragt, warum das Kompilieren seiner Anwendung fast 1 Stunde dauert. Als dann herauskam, dass er ca. 8000 Hinweise und Warnungen bekam, war alles klar. Nach 2 Tagen meldete er sich wieder und verkünderte, dass es nun ca. 30 Sekunden dauert, er aber einige Zeit beschäftigt gewesen sein, alle Warnungen und Hinweise zu beachten.
Aya - Do 20.02.03 18:40
Was soll ich denn gegen diese Fehlermeldung machen...??
Delphi 6 hat folgendes geschrieben: |
[Warning] Unit1.pas(7): Unit 'ShellCtrls' is specific to a platform |
Au'revoir,
Aya
hansa - Do 20.02.03 19:05
Hab ich das da geschrieben ? Glaube ja. 8)
Udontknow hat folgendes geschrieben: |
ich glaube, das solltest du näher erklären... Was ist für dich gültig? Wenn du alles initialisierst (so etwas tut man natürlich vor dem ersten Exit-Aufruf), wie sollte plötzlich durch Verwendung des Exits ein undefinierter Rückgabewert entstehen? |
@AYA : ich modifiziere mal Deinen Quelltext etwas:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16:
| const Version: 'DEMOO'; // <--------- z.B. Tastatur prellt, Tippfehler usw.
procedure CheckVersion; var x: Integer; begin if Version='DEMO' then begin x:=1; EXIT; END; else if Version='FULL' then begin x:=2 EXIT; end; end; |
Was steht dann in Result :?:
und was wäre wenn es so wäre :
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| procedure CheckVersion; var x: Integer; begin x := 0; if Version='DEMO' then x:=1 else if Version='FULL' then x:=2 end; end; |
Was ist nun besser, da bitte ich aber nun auch um Aufklärung. Bei AYAs Bsp. ist die Variable aber sowieso nicht initialisiert, ob mit oder ohne EXIT.
tommie-lie - Do 20.02.03 20:08
Aya hat folgendes geschrieben: |
Was soll ich denn gegen diese Fehlermeldung machen...??
Delphi 6 hat folgendes geschrieben: | [Warning] Unit1.pas(7): Unit 'ShellCtrls' is specific to a platform |
|
Windows benutzen *g*
Die Fehelrmeldung sagt, daß die besagte Unit nur für eine bestimmte Platformart zu benutzen ist.Vermutlich hast du versucht, sie in ein CLX-Programm einzubinden.
Aya - Do 20.02.03 20:11
Was die fehlermeldung mir sagen will is mir klar *g*
die meldung bekommt ihr, wenn ihr von dem "Samples"-Reiter z.B. den TShellTreeView o.ä benutzt...
und es ging ja hier darum alle Fehlermeldungen wegzubekommen, und bei der hab ich KA wie ich sie wegbekommen soll ;)
AndyB - Do 20.02.03 20:25
Du kannst ein
Quelltext
1: 2: 3:
| {$WARNING OFF} uses Windows, Messages, ..., ShellCtrls {$WARNING ON} |
einbauen.
tommie-lie - Do 20.02.03 21:15
Aber ich würde mich um sowas nicht kümmern. Wieso ist es (laut Elend) ein schlechter Eindruck, wenn beim kompilieren Warnungen erscheinen? Klar, initialisieren sollte man schon, aber es sind nur Warnungen. Die Sache mit dem "DEMO" und "DEMOO" finde ich viel schlimmer. Hätte man den Code überprüft, bzw beim Tippen aufgepasst, wäre es egal, ob man x erst auf 0 setzt oder nicht. Es ist höchstens interessant, wenn man den Quellcode weitergeben will, und da sind so Sachen wie "Irgendeine Unit könnte möglicherweise awoanders nicht laufen" extrem sinnvoll, und sollten nicht ausgeschaltet sein. So könnte zum Beispiel eine Unit Assembler-Code enthalten, der nur auf einem Intel-Prozessor läuft. Wäre es nicht für einen Programmierer sinnvoll zu erfahren, daß die Unit, die er sich gerade besorgt hat, nicht auf seinem Rechner läuft, weil er Amd-Anhänger ist? Oder was ist mit der "deprecated"-Warnung? Ich will doch wissen, daß eine Unit, die ich benutze, teilweise überaltert ist, bzw demnächst den Bach runter geht.
Wirklich Sorgen mache ich mir nur, wenn sich das [Warning] in ein [Error] verwandelt. Und so viele Warnings gibt's bei mir eigentlich auch nicht, da ich Variablen i.d.R. auch vorher irgendwie initialisiere, bevor ich sie benutze.
Udontknow - Do 20.02.03 21:47
@Hansa:
Das Beispiel von Aya eignet sich nicht unbedingt, um die Nützlichkeit von exit darzustellen, weil es eben nur eine einzige Bedingung ist, die abgeprüft wird.
Stelle dir aber mal vor du hast eine Funktion AlleBedingungenErfuellt, die 20 Bedingungen abprüfen muss. Ich initialisiere in diesem Falle Result mit False und springe, sobald eine der 20 Bedingungen nicht erfüllt ist, einfach mit exit heraus. Am Ende der Prozedur setze ich Result auf True.
Anderes Beispiel: Du suchst das erste Objekt in einer Liste, das ein bestimmtes Unterobjekt hat:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| function SucheObjekt(GesuchterName:String):TObjekt; var i,j:integer; begin Result:=NIL; for i:=0 to Objekte.Count-1 do for j:=0 to j do Objekte[i].UnterObjekte.Count-1 do if Objekte[i].UnterObjekte[j].Name=Gesucht then begin Result:=Objekte[i]; exit; end; end; |
OHne die Verwendung von exit ist das schon ein wenig komplexer: Aus den For-Schleifen werden plötzlich While-Schleifen mit der zusätzlichen Bedingung "and (Result<>NIL). In der While-Schleife selbst muss dann noch die Zählervariable erhöht werden. Die einzige Alternative zu den While-Schleifen wäre das Verlassen der For-Schleifen mittels Break, wobei das auch in zusätzlichen Abprüfungen endet. Übersichtlicher wird es auf gar keinen Fall.
Cu,
Udontknow
Udontknow - Do 20.02.03 21:49
@ Tommie Lie: Warnungen sind sehr häufig "Zeitbomben", also Fehlerquellen, die erst zur Laufzeit sich bemerkbar machen.
Cu,
Udontknow
tommie-lie - Do 20.02.03 21:56
schon klar.
Natürlich kann eine Systemabhängige Unit bei einigen Rechnern dazu führen, daß das Programm nicht wie erwartet läuft. Aber hier war ja wohl die frage, wie man diese "lästigen" Meldungen wegmachen kann. Und das sollte man IMHO nicht machen, sondern sie lieber da stehen lassen, damit jeder, der versucht, den Code selbst zu kompilieren merkt, daß die und die Unit nicht ganz aktuell ist, oder die und die eben nicht überall läuft.
Man kann die Meldungen zwar mit $WARNS ausschalten, sollte dies aber nicht tun. Das war meine Aussage.
hansa - Do 20.02.03 22:15
Zitat: |
werden plötzlich While-Schleifen mit der zusätzlichen Bedingung "and (Result<>NIL). |
auf Result verzichte ich ja auch. :mrgreen: Nee, im Ernst, habe mir mal eines meiner großen Programme angeschaut, das hat über 50000 Zeilen eigenen Quelltext. Da ist kein Exit oder so was drin. Aus Erfahrung habe ich das alles eliminiert. Es geht auch anders. Wer Exit und Result benutzen will ? Ich hindere ihn nicht. Was passiert denn eigentlich, wenn ich result lokal oder global selber deklariere :?: Hmm :shock: .
Udontknow - Fr 21.02.03 10:10
Ganz abgesehen davon, daß es nicht gerade der Lesbarkeit des Codes dienlich ist, eine Variable Result zu definieren:
Lokal kannst du es in einer Funktion nicht definieren, du erhälst einen Compilerfehler("Bezeichner redifiniert."). Global kannst du auf die Variable zugreifen, indem du explizit die Unit bzw. das Objekt angibst, wo die Variable definiert wurde:
Quelltext
1: 2: 3: 4: 5: 6: 7:
| function TForm1.Test: Integer; begin Result:=3; Unit1.Result:=4; ShowMessage(IntToStr(Result)); ShowMessage(IntToStr(Unit1.Result)); end; |
Wie jetzt, du benutzt auch nicht Result? Schreibst du keine Funktionen? Niemals? Das kann ich fast nicht glauben... :shock:
Jetzt würde mich wirklich mal interessieren, wie du mein Beispiel umsetzen würdest. Mach das bitte mal.
Cu,
Udontknow
Klabautermann - Fr 21.02.03 11:13
Hallo,
Aya hat folgendes geschrieben: |
Was soll ich denn gegen diese Fehlermeldung machen...??
Delphi 6 hat folgendes geschrieben: | [Warning] Unit1.pas(7): Unit 'ShellCtrls' is specific to a platform |
|
diese Warnung finde ich wiederum extrem wichtig für CLX Anwendungen. Sie weißt darauf hin wann du diese Platformunabhängigkeit verletzt.
Das darfst und musst du mitunter machen, aber dann solltest du sicherstellen, das der Entsprechende Programmteil auch nur unter dem Betriebsystem mit einkompiliert wird für den er ist:
Quelltext
1: 2:
| uses SysUtils, Types, Classes, Variants, QTypes, QGraphics, QControls, QForms, QDialogs, QStdCtrls, QComCtrls, QFileCtrls {$IFDEF Win32}, ShellCtrls{$ENDIF} {$IFDEF LINUX}, CLIB{$ENDIF}; |
Allerdings muss ich grade feststellen das dadurch die Warnung nicht verschwindet. Auch wird sie in VCL Projekten angezeigt, wo sie meiner Meinung nach, nichts zu suchen hat. Entweder da weicht Borlands Philosophie von meiner ab oder es hat jemand beim Inplementieren dieser Warnung geschlammpt.
Gruß
Klabautermann
Tino - Fr 21.02.03 12:08
Udontknow hat folgendes geschrieben: |
Lokal kannst du es in einer Funktion nicht definieren, du erhälst einen Compilerfehler("Bezeichner redifiniert."). |
Nicht ganz. Wenn du die bestimmte Compilerschalter setzt geht das schon da der Compiler dann keine Result Varialbe in den Code einbaut.
Udontknow hat folgendes geschrieben: |
Jetzt würde mich wirklich mal interessieren, wie du mein Beispiel umsetzen würdest. Mach das bitte mal. |
Eventl. so:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8:
| function TForm1.Test: Integer; begin Test := 3;
Unit1.Result:=4; ShowMessage(IntToStr(Result)); ShowMessage(IntToStr(Unit1.Result)); end; |
Gruß
TINO
hansa - Fr 21.02.03 12:56
@Udontknow : Tino kam mir offenbar etwas zuvor. :D
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| function TForm1.Test: Integer; begin Test:=3; Unit1.UnitTest:=4; end;
procedure TForm1.Button1Click(Sender: TObject); begin IF Test = 0 THEN; ShowMessage('TEST '+IntToStr(Test)); ShowMessage('UNIT '+IntToStr(Unit1.UnitTest)); end; |
willst Du das showmessage innerhalb der Funktion :
Quelltext
1: 2: 3: 4: 5: 6: 7: 8:
| function TForm1.Test: Integer; var t : integer; begin t := 3; Test:=t; Unit1.UnitTest:=4; ShowMessage (IntToStr (t)); end; |
Udontknow - Fr 21.02.03 15:41
@Tino & Hansa:
Hansa schrieb:
Zitat: |
Was passiert denn eigentlich, wenn ich result lokal oder global selber deklariere |
Ich schrieb:
Zitat: |
Lokal kannst du es in einer Funktion nicht definieren, du erhälst einen Compilerfehler("Bezeichner redifiniert."). |
Tino schrieb:
Zitat: |
Nicht ganz. Wenn du die bestimmte Compilerschalter setzt geht das schon da der Compiler dann keine Result Varialbe in den Code einbaut. |
Oh wirklich? Wie lauten die Compilerschalter? Anyway, ohne Compilerschalter klappt es nicht. Und ihr habt irgendwie Funktionen gepostet, wo Result eben nicht lokal deklariert wird.
Aber abgesehen davon: Mit "mein Beispiel" meinte ich die Funktion SucheObjekt, die ich weiter oben gepostet hatte. Wie würdest du sie ohne exit realisieren, Hansa?
Cu,
Udontknow
hansa - Sa 22.02.03 22:42
na gut, ohne EXIT, Result usw.:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22:
| var ende, gefunden : boolean; i, j : integer; T : Tobjekt; begin i := 0; T := NIL; ende := false; gefunden := false; while not ende and (i < objekte.count) do begin i := i + 1; j := 0; while not ende and (j < objekte.unterobjekte.count[j]) do begin j := j + 1; gefunden := objekte[i].unterobjekte [j].name := gesucht; ende := gefunden; end; if gefunden then SucheObjekt := objekte[i].unterobjekte [j].name; end; |
Udontknow - So 23.02.03 16:02
Und nochmal zum Vergleich:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| function SucheObjekt(GesuchterName:String):TObjekt; var i,j:integer; begin Result:=NIL; for i:=0 to Objekte.Count-1 do for j:=0 to j do Objekte[i].UnterObjekte.Count-1 do if Objekte[i].UnterObjekte[j].Name=Gesucht then begin Result:=Objekte[i]; exit; end; end; |
Ich denke, nun ist es klar, dass das Aussenvorlassen von exit so manchen Code zum italienischen Spaghetti-Code verkommen lässt. :wink:
Cu,
Udontknow
hansa - So 23.02.03 17:20
Udontknow hat folgendes geschrieben: |
Und nochmal zum Vergleich |
Vergleiche nicht Äpfel mit Birnen. Dein Code ist vielleicht etwas kürzer zum tippen, aber es geht doch darum, ob man EXIT nun braucht oder nicht. Das ist hier die Frage. Oder nicht :?: Und jetzt : braucht man das wirklich ? Übrigens : mein Code ist weder getestet, noch optimiert.
Udontknow - So 23.02.03 19:17
Zitat: |
aber es geht doch darum, ob man EXIT nun braucht oder nicht. Das ist hier die Frage |
Man
braucht auch keine OOP, um zu programmieren. Man braucht auch kein Delphi. Man braucht auch keinen Monitor. Lochkarten tun´s ja auch. :wink:
Es geht nicht darum, ob die Anwendung von exit obligatorisch ist oder nicht, es geht um Übersichtlichkeit, um Verständlichkeit, um Lesbarkeit von Code. Und der ist in so manchen Situationen einfach besser lesbar, wenn exit eingesetzt wird. Die Fehleranfälligkeit des Codes ist dann einfach geringer. Vergleiche doch nur mal die Anzahl der Bedingungen oder der benötigten Variablen in den Routinen.
Je weniger Codezeilen du hast, um so übersichtlicher ist dein Programm (komm mir jetzt keiner mit 20 Befehlen in einer Zeile, ihr wisst, was ich meine).
Cu,
Udontknow
hansa - So 23.02.03 19:23
also braucht mans doch nicht unbedingt oder doch? :mrgreen: Was denn nu ? Auf 5 Zeilen mehr oder weniger kommts wohl nicht an.
Udontknow - So 23.02.03 22:11
LOL! :)
Hansa, du bist mir einer! Ich habe nur gesagt, daß Code sehr viel übersichtlicher damit wird. In deinem vorletzten Post erklärst du "aber es geht doch darum, ob man EXIT nun braucht oder nicht". Daraufhin teilte ich dir mit, daß es nicht um "Brauchen" geht sondern um Übersichtlichkeit,
und jetzt tust du so, als hätte ich irgendwann behauptet, daß die Verwendung von exit obligatorisch wäre.
Nenene, Rethorik vom feinsten! :wink:
Also, noch einmal:
Kürzerer Code -> Übersichtlicherer Code -> geringere Fehleranfälligkeit.
Zitat: |
Auf 5 Zeilen mehr oder weniger kommts wohl nicht an. |
Das ist doch nur ein Beispiel. Der möglichen Komplexität sind keine Grenzen gesetzt. Dementsprechend sind auch die Einsparungen und die Steigerung der Lesbarkeit.
Cu,
Udontknow
hansa - Mo 24.02.03 00:09
ich brauche ein Beispiel, daß es ohne EXIT nicht geht.
AndyB - Mo 24.02.03 00:46
hansa hat folgendes geschrieben: |
ich brauche ein Beispiel, daß es ohne EXIT nicht geht. |
Das gibt es nicht, da du es mit einer oder mehreren boolschen Variablen und if bzw. Break nachprogrammieren kannst. Aber ob das dann noch übersichtlich ist, sei dahingestellt.
Als Alternative kann man ja noch mit
GoTo arbeiten. :lol:
hansa - Mo 24.02.03 00:55
AndyB hat folgendes geschrieben: |
Als Alternative kann man ja noch mit GoTo arbeit |
ja, das fehlt ja noch. Vorher hat sich niemand getraut, dieses Wort auszusprechen. :shock:
Udontknow - Mo 24.02.03 10:25
Zitat: |
ich brauche ein Beispiel, daß es ohne EXIT nicht geht. |
Ja, warum denn? Liebe Güte, ich rede eigentlich die ganze Zeit nur von Übersichtlichkeit & Wartbarkeit von Code. Wie kommst du denn jetzt auf den Trichter, daß irgendjemand gesagt hätte, ohne Exit gehe es nicht?
Cu,
Udontknow
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 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!