Tutorial Debugging - Versionsgeschichte

Glawesome: /* Debug Desktops */ Kategoriefehler

2014-03-02T22:20:52Z

‎Debug Desktops: Kategoriefehler

DGLBot: Der Ausdruck ''(.*?)'' wurde ersetzt mit ''$1''.

2009-03-10T18:12:00Z

Der Ausdruck ''<pascal>(.*?)</pascal>'' wurde ersetzt mit ''<source lang="pascal">$1</source>''.

Nico Michaelis: /* Grundkurs im Käfer entfernen */

2008-04-06T16:09:21Z

‎Grundkurs im Käfer entfernen

Nico Michaelis: /* Einführung in den Delphi Debugger */ Kleine Formulierungen

2008-04-06T11:40:25Z

‎Einführung in den Delphi Debugger: Kleine Formulierungen

Nico Michaelis: /* Ich habe nichts geändert, aber jetzt funktionierts nicht mehr */ Links modernisiert

2008-04-06T11:27:57Z

‎Ich habe nichts geändert, aber jetzt funktionierts nicht mehr: Links modernisiert

MyChaOS: + Navi

2005-12-26T11:13:15Z

+ Navi

I0n0s: /* Grundkurs im Käfer entfernen */ +s

2005-12-26T03:11:14Z

‎Grundkurs im Käfer entfernen: +s

BenBE am 25. Dezember 2005 um 21:17 Uhr

2005-12-25T21:17:27Z

BenBE: /* Ich habe nichts geändert, aber jetzt funktionierts nicht mehr */

2005-12-25T21:12:27Z

‎Ich habe nichts geändert, aber jetzt funktionierts nicht mehr

BenBE: /* Haltepunkte, Haltebedingungen und andere nützliche Werkzeuge */

2005-12-25T21:11:00Z

‎Haltepunkte, Haltebedingungen und andere nützliche Werkzeuge

← Nächstältere Version		Version vom 2. März 2014, 22:20 Uhr
Zeile 256:		Zeile 256:
	{{TUTORIAL_NAVIGATION\|-\| [[Tutorial Komponentenentwicklung]]}}		{{TUTORIAL_NAVIGATION\|-\| [[Tutorial Komponentenentwicklung]]}}

−	[[Kategorie:Tutorial\|~~Komponentenentwicklung~~]]	+	[[Kategorie:Tutorial\|Debugging]]

@@ Zeile 32: / Zeile 32: @@
 Wenn man nun beispielsweise über die Grenzen eines Arrays hinauslangt, wird man von Delphi freundlich darauf aufmerksam gemacht: [[Bild:Rangecheck.gif]]
-<pascal>
+<source lang="pascal">
 procedure TForm1.FormCreate(Sender: TObject);
 var
@@ Zeile 42: / Zeile 42: @@
      P[i] := 15- Random(30);
 end;
-</pascal>
+</source>
 Der Debugger springt an die fehlerhafte Zeile und man kann das Problem lösen, aber dazu später mehr. In diesem Falle ist der Fehler natürlich sehr offensichtlich und auch ohne Debugger problemlos zu finden.
@@ Zeile 148: / Zeile 148: @@
 Delphi ermöglicht Anweisungen, die einfach leer sind und nur aus einem Semikolon bestehen. Das führt schon mal zu Problemen:
-<pascal>
+<source lang="pascal">
 var
    i, k : Integer;
@@ Zeile 158: / Zeile 158: @@
    end;
    ...
-</pascal>
+</source>
 Anders als wahrscheinlich erwartet, wird dieser Code nicht die Fakultät aus k errechnen. Stattdessen wird die leere Anweisung ";" (k-1)mal ausgeführt. Ein Entfernen des Strichpunktes und alles läuft wieder wie gewollt. Finden würde man diesen Fehler im Einzelschritt: Die rechnende Zeile würde nämlich einfach nur 1 mal ausgeführt werden.
@@ Zeile 165: / Zeile 165: @@
 Manchmal benutzt man Variablen aus einem falschen Gültigkeitsbereich, die eigentlich für einen anderen Zweck bestimmt waren. Besonders häufig beschädigt man Zählvariablen, etwa das von vielen sehr geliebte i als Variablenname:
-<pascal>
+<source lang="pascal">
 var
    i : Integer;
@@ Zeile 184: / Zeile 184: @@
      DoSomething(i);
 end.
-</pascal>
+</source>
 Dieses Programm wird nie ein Ende finden und nur massenhaft Sternchen auf den Bildschirm zeichnen, da die Variable i durch DoSomething immer schön zurückgesetzt wird und die for Schleife damit nie ans Ende kommt. Beim Debuggen sollte einem auffallen, dass nach DoSomething die Zählvariable i immer einen falschen Wert hat. Ein entsprechender Programmierstil würde helfen, solche Probleme in Zukunft zu vermeiden: Variablen die nur lokal benötigt werden, wirklich nur für den entsprechenden Abschnitt zu definieren und damit den Zugriff durch andere Funktionen zu unterbinden.
@@ Zeile 205: / Zeile 205: @@
 Objektorientierte Programmierung. Ein schönes Wort. Jedoch mit vielen Tücken. Eine Variable auf ein Form : TForm ist z.B. nichts anderes als ein Pointer. Delphi versteckt das Pointerproblem vor dem Entwickler recht gut, so dass er nicht ständig und überall dereferenzieren muss. Das hat aber auch seine Nachteile, besonders bei Objekten, die nicht nach Objekten aussehen(oder gar keine sind, sich aber so ähnlich verhalten):
-<pascal>
+<source lang="pascal">
    procedure LoadCompressedTGA(...);
    var
@@ Zeile 219: / Zeile 219: @@
        ...
    end; (*LoadCompressedTGA*)
-</pascal>
+</source>
 Hier liegt die Krux im BlockRead begraben. Was daran falsch ist? ColorBuffer ist als solches nur ein Pointer, der auf die Informationen des dynamischen Arrays zeigt. Wendet man das Blockread nun tatsächlich so an, wird nur der Pointer überschrieben, nicht aber die Daten, die überschrieben werden sollten. Wir geben BlockRead also den falschen Pointer mit - wir müssten eigentlich diesen "Pointer" derart dereferenzieren, dass er auf die Daten zeigt, was z.B. mittels ColorBuffer[0] ginge. Dieser Fehler wird sehr häufig begangen, besonders im Umgang mit Dateien. Allerdings sind nicht nur dynamische Arrays betroffen, sondern die von Delphi als Standard eingestellten Huge Strings und Ähnliche.

@@ Zeile 128: / Zeile 128: @@
 Jetzt kennen wir alle Elementaren Fähigkeiten des Delphi Debuggers. Wesentlich wichtiger ist jedoch, damit umgehen zu können. Jeder Programmierer entwickelt mit der Zeit seinen eigenen Programmier- und Debugstil. Das bedeutet allerdings, dass ich hier nur Tipps zum Debuggen geben kann, nicht jedoch Erfolgsrezepte. Debugging besteht nun mal aus Intuition und Erfahrung, aber man kann sich die Sache ganz schön erleichtern.
-Worauf man immer achten kann ist, wie schwer man sich das Fehlerfinden macht. Muss man älteren Code debuggen, oder den eines anderen Programmierers, so sind Kommentare mit das wertvollste, was es gibt. Andererseits sollte man bei seinem Code auch darauf achten, dass er sich später leicht debuggen lässt, etwa seine Programme so Modular designen, dass man später leicht einen einzelnen Bereich des Programms alleine begutachten kann, ohne gleich einen riesigen Schwanz an anderen Funktionen ständig mitrumschleppen zu müssen - sprich: Debuggen wird umso leichter, je besser man sich auf den Code konzentrieren kann, in dem der Fehler vermutet wird, ohne dass man durchgehend von anderem Code abgelenkt wird. Das entsprechende Stichwort ist '''strukturierte Programmierung'''.
+Worauf man immer achten kann ist, wie schwer man sich das Fehlerfinden macht. Muss man älteren Code debuggen, oder den eines anderen Programmierers, so sind Kommentare mit das wertvollste. Andererseits sollte man bei seinem Code auch darauf achten, dass er sich später leicht debuggen lässt, etwa seine Programme so Modular designen, dass man einen einzelnen Bereich des Programms alleine begutachten kann, ohne gleich einen riesigen Schwanz an anderen Funktionen ständig mitrumschleppen zu müssen - sprich: Debuggen wird umso leichter, je besser man sich auf den Code konzentrieren kann, in dem der Fehler vermutet wird, ohne dass man durchgehend von anderem Code abgelenkt wird. Das entsprechende Stichwort ist '''strukturierte Programmierung'''.
 Daneben sollte man in Funktionen sog. Assertions einfügen. Sie sind Annahmen. Etwa, dass die Funktion niemals mit dem Parameter  '''I < 0''' aufgerufen werden darf, oder ihr Ergebnis niemals 0 sein darf, da es dann an anderer Stelle knackt, oder Speicherbereiche überschrieben werden, die eben nicht überschrieben werden sollten. Entsprechende Annahmen kann man mit dem Befehl '''Assert(Bedingung)''' in seinen Code einpflegen. Ist die Bedingung nicht erfüllt, wird man darauf aufmerksam gemacht.
@@ Zeile 135: / Zeile 135: @@
 === Kuscheltier Zweckentfremdung ===
-Kuscheltiere sind leidensfähige Zuhörer, sie quengeln nicht und motzen nicht rum, wenn man sie mit langweiligen Dingen quält. Das macht sie zu einem idealen Gesprächspartner. Probiert es aus: Erklärt eurem Kuscheltier, dass ihr euch neben den Monitor gesetzt habt euer Problem in allen Details, was ihr eigentlich haben wolltet und eure Vermutungen. Versucht euch in anständiger Sprache auszudrücken - was das bringt fragt ihr? Ganz einfach, drückt man seine Gedanken in Worten aus, so ordnen sich die Gedanken im Hirn und die Lösung springt einen meist regelrecht an. Und hier ist der nächste Vorteil eines Kuscheltiers - auch wenn der Fehler noch so lächerlich ist, das Kuscheltier wird euch nicht auslachen. Es wird auch nicht zu grinsen anfangen, wenn ihr voll Freude in die Luft springt, weil ihr den lang gesuchten Fehler endlich gefunden habt.
+Kuscheltiere sind leidensfähige Zuhörer, sie quengeln nicht und motzen nicht rum, wenn man sie mit langweiligen Dingen quält. Das macht sie zu einem idealen Gesprächspartner. Probiert es aus: Erklärt eurem Kuscheltier, dass ihr euch neben den Monitor gesetzt habt euer Problem in allen Details, was ihr eigentlich haben wolltet und eure Vermutungen. Versucht euch in anständiger Sprache auszudrücken - was das bringt? Ganz einfach, drückt man seine Gedanken in Worten aus, so ordnen sich die Gedanken im Hirn und die Lösung springt einen meist regelrecht an. Und hier ist der nächste Vorteil eines Kuscheltiers - auch wenn der Fehler noch so lächerlich ist, das Kuscheltier wird euch nicht auslachen. Es wird auch nicht zu grinsen anfangen, wenn ihr voll Freude in die Luft springt, weil ihr den lang gesuchten Fehler endlich gefunden habt.
 Sollte euch einmal kein Kuscheltier zur Verfügung stehen, versucht euch an Eltern, Kollegen, Lehrern... Die sind zwar nicht ganz so gut geeignet, aber wenn man einen hartnäckigen Fehler sucht, muss man auch mal Opfer bringen ;-)
@@ Zeile 189: / Zeile 189: @@
 ==== Initialisieren ====
-Für hochgradig interessante Effekte sorgen immer wieder nicht initialisierte Variablen, die dadurch irgendwelche zufälligen Werte enthalten und dadurch den Ablauf des Programms erheblich stören können. Wer Variablen verwendet, denen nie ein Wert zugewiesen wurde, darf sich nicht wundern - das ganze kann aber richtig knackig werden: Manche Debugger initialisieren neue Variablen während dem Debuggen mit 0, während ohne Debugger die Variable eben nicht initialisiert wird - spätestens wenn sich ein Programm im Debugger anders verhält, als wie in freier Wildbahn, sollten die Alarmglocken läuten. Wer sich angewöhnt, nachdem er eine Variable definiert hat, ihr auch gleich eine Initialisierungszeile zu spendieren wird dieses Problem nie wieder haben - es sei denn er hat sie mit einem falschen Wert initialisiert... Glücklicherweise wird man von Delphi über Hints auf so etwas meist aufmerksam gemacht - den Grund solcher Warnmeldungen sollte man in jedem Falle einmal nachgehen.
+Für hochgradig interessante Effekte sorgen immer wieder nicht initialisierte Variablen, die dadurch irgendwelche zufälligen Werte enthalten und dadurch den Ablauf des Programms erheblich stören können. Wer Variablen verwendet, denen nie ein Wert zugewiesen wurde, darf sich nicht wundern - das ganze kann aber richtig knackig werden: Manche Debugger initialisieren neue Variablen während dem Debuggen mit 0, während ohne Debugger die Variable eben nicht initialisiert wird - spätestens wenn sich ein Programm im Debugger anders verhält, als wie in freier Wildbahn, sollten die Alarmglocken läuten. Wer sich angewöhnt, nachdem er eine Variable definiert hat, ihr auch gleich eine Initialisierungszeile zu spendieren wird dieses Problem nie wieder haben - es sei denn er hat sie mit einem falschen Wert initialisiert... Glücklicherweise wird man von Delphi über Hints auf so etwas aufmerksam gemacht - den Grund solcher Warnmeldungen sollte man in jedem Falle einmal nachgehen.
 ==== Memory is running out ====
@@ Zeile 195: / Zeile 195: @@
 ==== Speicherlecks ====
-Tropfende Speicherlecks sind eine andere Bösartigkeit. Manchmal langt man durch sie in den Speicher eines anderen Programms - unter Windows NT gibt es einen Abbruch, unter Win9x wird einfach überschrieben, was daraus auch immer am Ende resultiert. Das wäre noch nicht einmal das Problem, denn dann findet man den Fehler meist schnell.
+Tropfende Speicherlecks sind eine andere Bösartigkeit. Manchmal langt man durch sie in den Speicher eines anderen Programms - unter Windows NT gibt es einen Abbruch, unter Win9x wird einfach überschrieben, was daraus auch immer resultiert. Das wäre noch nicht einmal das Problem, denn dann findet man den Fehler meist schnell.
 Unangenehmer wird es schon, wenn man seinen eigenen Speicher überschreibt. Das Betriebssystem beschwert sich nicht, aber die Werte der Variablen, die an entsprechenden Speicherstellen standen sind nun mit unsäglichem Unsinn überschrieben. Besonders anfällig sind Funktionen wie Move oder FillChar, aber auch Arrays, wenn die Bereichsprüfung deaktiviert ist. Besonders bei Objekt ähnlichen Konstrukten überschreibt man manchmal den Pointer, nicht aber die Daten(Siehe später: It's magic, real magic - oder Zeigerprobleme die Zweite).
@@ Zeile 221: / Zeile 221: @@
 </pascal>
-Hier liegt die Krux im BlockRead begraben. Was daran falsch ist? ColorBuffer ist als solches nur ein Pointer, der auf die Informationen des dynamischen Arrays zeigt. Wendet man das Blockread nun tatsächlich so an, wird nur der Pointer überschrieben, nicht aber die Daten, die
+Hier liegt die Krux im BlockRead begraben. Was daran falsch ist? ColorBuffer ist als solches nur ein Pointer, der auf die Informationen des dynamischen Arrays zeigt. Wendet man das Blockread nun tatsächlich so an, wird nur der Pointer überschrieben, nicht aber die Daten, die überschrieben werden sollten. Wir geben BlockRead also den falschen Pointer mit - wir müssten eigentlich diesen "Pointer" derart dereferenzieren, dass er auf die Daten zeigt, was z.B. mittels ColorBuffer[0] ginge. Dieser Fehler wird sehr häufig begangen, besonders im Umgang mit Dateien. Allerdings sind nicht nur dynamische Arrays betroffen, sondern die von Delphi als Standard eingestellten Huge Strings und Ähnliche.
 ==== Knack knack: Access Violation bei Arrays oder wer kann hier nicht zählen? ====

@@ Zeile 21: / Zeile 21: @@
 Üben, üben, üben... Vielleicht löst ihr dann ja auch mal unsere Probleme, wenn wir unsere Fehler nicht finden. Und lasst euch nicht entmutigen, wenn ihr mal einen Nachmittag nur am Debuggen seid, das passiert manchmal und liegt meist an '''irgendeiner saudummen''' Zeile, nach der man wahrlich lange sucht.
-Gute Debugging Fähigkeiten verleiten einen aber auch... Einfach etwas Code ohne groß Nachzudenken hinklatschen, dann mit dem Debugger drüber und alle Fehler ausmerzen - das ist nicht nur schlechter Stil, sondern frisst meist mehr Zeit, als sich vorher 10 Minuten mehr Zeit zu nehmen um etwas zu überlegen und so erst gar keine Probleme zu bekommen. Kurz: Wer nur noch mit dem Debugger rumwurschtelt macht was falsch.
+Gute Debugging Fähigkeiten verleiten einen aber auch... Einfach etwas Code ohne groß Nachzudenken hinklatschen, dann mit dem Debugger drüber und alle Fehler ausmerzen - das ist nicht nur schlechter Stil, sondern frisst mehr Zeit, als sich vorher 10 Minuten mehr Zeit zu nehmen um etwas zu überlegen und so erst gar keine Probleme zu bekommen. Kurz: Wer nur noch mit dem Debugger rumwurschtelt macht was falsch! Programmieren ist eine Kopfsache, die man immer mit Papier und Bleistift beginnt - Code schreiben darf höchstens vorletzter Schritt sein.
 === Wichtige Voreinstellungen ===
@@ Zeile 57: / Zeile 57: @@
 [[Bild:Breakpoint.gif]]
-Die blauen Punkte am Rand bedeuten, dass an dieser Zeile ein Breakpoint gesetzt werden kann. Eine Rote Zeile steht für einen aktiven Breakpoint. Klickt man auf einen blauen Punkt, so setzt man einen Breakpoint.
+Die blauen Punkte am Rand bedeuten, dass an dieser Zeile ein Breakpoint gesetzt werden kann. Eine Rote Zeile steht für einen aktiven Breakpoint. Klickt man auf einen blauen Punkt, so setzt man ihn.
 Startet man nun das Programm, hält das Programm immer an, wenn der Breakpoint im Programmablauf erreicht wird. Aber Breakpoints können noch einiges mehr. Klickt man mit rechts auf den roten Punkt, kann man einen Breakpoint deaktivieren (Aktiviert abwählen -> Breakpoint wird grün umgefärbt), auf diese Weise findet man ihn schnell wieder, falls man ihn nochmal braucht, denn so befindet er sich weiterhin in der Liste der Haltepunkte (CTRL+ALT+B):
@@ Zeile 63: / Zeile 63: @@
 [[Bild:Breakpointlist.gif]]
-Sie zeigt eine schöne Übersicht aller gesetzten Breakpoints. Das kleine linke Symbol zeigt den Zustand an, grau z.B. für deaktiviert. Andere wichtige Information, wie Quelldatei, Lage, Bedingungen usw. kann man auch gleich einsehen.
+Sie zeigt eine schöne Übersicht aller gesetzten Breakpoints. Das kleine linke Symbol zeigt den Zustand an, grau z.B. für deaktiviert. Andere Information, wie Quelldatei, Lage, Bedingungen usw. kann man auch gleich einsehen.
-Breakpoints können aber nicht nur stupide den Code anhalten, man kann sie auch so bearbeiten, dass sie nur in bestimmten Situationen ausschlagen, das ist besonders wertvoll, wenn man mit Schleifen arbeitet, die mehrere hundert Durchläufe machen.
+Breakpoints können aber nicht nur stupide den Code anhalten, man kann sie auch so bearbeiten, dass sie nur in bestimmten Situationen ausschlagen, das ist nicht nur wertvoll, wenn man mit Schleifen arbeitet, die mehrere hundert Durchläufe machen.
 ==== Hit-Count Breakpoints ====

@@ Zeile 7: / Zeile 7: @@
 Dieses Problem läuft einem so verdammt oft über den Weg. Ob ihr es glaubt oder nicht, meistens hat man doch etwas geändert, man erinnert sich nur nicht, oder verbindet die Änderung nicht mit seinem Problem.
-In der Professionellen Programmierung gibt es ein einfaches System, das einem solche Probleme vom Leibe hält, warum sollte man also als Hobbyprogrammierer darauf verzichten? Ich rede von Version Controll Systemen. Ein freies, das auch gut in die Delphi IDE integriert ist [http://www.thensle.de/oldbrows.htm Free VCS]. Leider wurde dieses Projekt eingestellt, wird aber von den Jedis weitergeführt: [http://jedivcs.sourceforge.net/ Jedi VCS]. Solange Jedi VCS allerdings noch keine stable Versionen veröffentlicht hat, langt Free VCS mit Sicherheit.
+In der Professionellen Programmierung gibt es ein einfaches System, das einem solche Probleme vom Leibe hält, warum sollte man also als Hobbyprogrammierer darauf verzichten? Ich rede von Version Controll Systemen. Bekannt sind hier besonders CVS und sein Nachfolger [http://subversion.tigris.org/ Subversion], welches unter Windows am besten mittels [http://tortoisesvn.tigris.org/ Tortoise SVN] bedient. GUI liebende Unix User werden dagegen mit [http://rapidsvn.tigris.org/ Rapid SVN] glücklich (Läuft auch unter Windows, falls jemand die Explorer Einbindung von Tortoise SVN nicht so recht abkann).
 Nun was bringen einem VCS Systeme? Für den einzelnen Hobbyprogrammierer eher unwichtig, für Gruppen allerdings umso wichtiger: Jeder Nutzer kann sich Dateien vom Server laden und den Schreibzugriff für sich reservieren lassen. Wenn er fertig ist, schickt er die veränderte Datei zurück an den Server. Der Server Archiviert die neue Datei. Er überschreibt aber die Datei nicht wild, sondern behält immer eine ganze Reihe an Dateien. Und hier liegt der Vorteil für den Einzelnen: Man kann die unterschiedlichen Dateiversionen mit dem beiliegendem Diff Tool des jeweiligen VCS Systems einfach vergleichen und bekommt je nach System gleich eine hübsche Gegenüberstellung der beiden Versionen aus dem Archiv. Wenn man sich mal etwas Code richtig zerschossen hat, kann man leicht mal eine ältere Version aus dem Archiv nehmen und damit weiterarbeiten.

← Nächstältere Version		Version vom 26. Dezember 2005, 11:13 Uhr
Zeile 252:		Zeile 252:

	Euer Delphic		Euer Delphic
		+
		+
		+
		+	{{TUTORIAL_NAVIGATION\|-\| [[Tutorial Komponentenentwicklung]]}}
		+
		+	[[Kategorie:Tutorial\|Komponentenentwicklung]]

@@ Zeile 1: / Zeile 1: @@
 == Debugger benutzen und andere praktische Tipps ==
-Ich muss im DGL und anderen Foren immer wieder feststellen, dass Fragen zu Problemen gestellt werden, die sich mit etwas Know How stressfrei bewältigen ließen. Die Titel solcher Themen sind meist: ''"Hilfe, kann Fehler nicht finden", "Kann mir einer bei dem Problem helfen?", "Was ist falsch an diesem Code"'', ...
+Ich muss im DGL und anderen Foren immer wieder feststellen, dass Fragen zu Problemen gestellt werden, die sich mit etwas Know How stressfrei bewältigen ließen. Die Titel solcher Themen sind meist: ''"Hilfe, kann Fehler nicht finden"'', ''"Kann mir einer bei dem Problem helfen?"'', ''"Was ist falsch an diesem Code"'', ...
 Delphi und die meisten anderen Entwicklungsumgebungen bringen bereits das meiste mit, was man zum Debuggen braucht. Der Delphi Debugger ist meiner Meinung nach sogar einer der besten.
@@ Zeile 49: / Zeile 49: @@
 sog. Breakpoints. Werden sie erreicht, springt der Debugger
 am Breakpoint in den Code und ihr könnt euch genau anschauen
-was passiert. Beginnen wir zuerst mit der Bedienung:<br>
+was passiert. Beginnen wir zuerst mit der Bedienung:
 #Compiliert eure Quelldateien (Strg+F9)
@@ Zeile 110: / Zeile 110: @@
 === Ansichtssache ===
-Wer hat noch nie jemanden bei einer Tätigkeit beobachtet? Etwa,
+Wer hat noch nie jemanden bei einer Tätigkeit beobachtet? Etwa, wie er sich etwas zu essen macht? Seh ich da keine Hand? Lügner! Jedenfalls sind wir alle Voyeure. Leute die Debugger benutzen sogar in höchster Ausprägung, denn die schauen ständig Variablen auch bei ihren intimsten Tätigkeiten zu. Egal wie unwohl sie sich dabei fühlen, das muss einfach sein, ob sie wollen oder nicht - auch beim Akt der Vereinigung ;-).
-Mit Delphi geht das ganz einfach, man braucht nicht einmal ein
+Mit Delphi geht das ganz einfach, man braucht nicht einmal ein Fernglas. Wenn das Programm vom Debugger angehalten wurde, bewege man im Quelltext einfach die Maus über eine Variable und siehe da: Die enthaltene Information erscheint. Manchmal will man aber auch etwas genauer hinschauen, etwa den Inhalt eines Arrays an der Stelle, die gerade gelesen wird. Hier langt es, die entsprechende Stelle zu markieren:
 [[Bild:Watch-mouseover.gif]]
@@ Zeile 139: / Zeile 127: @@
 Jetzt kennen wir alle Elementaren Fähigkeiten des Delphi Debuggers. Wesentlich wichtiger ist jedoch, damit umgehen zu können. Jeder Programmierer entwickelt mit der Zeit seinen eigenen Programmier- und Debugstil. Das bedeutet allerdings, dass ich hier nur Tipps zum Debuggen geben kann, nicht jedoch Erfolgsrezepte. Debugging besteht nun mal aus Intuition und Erfahrung, aber man kann sich die Sache ganz schön erleichtern.
-Worauf man immer achten kann ist, wie schwer man sich das Fehlerfinden macht. Muss man älteren Code debuggen, oder den eines anderen Programmierers, so sind Kommentare mit das wertvollste, was es gibt. Andererseits sollte man bei seinem Code auch darauf achten, dass er sich später leicht debuggen lässt, etwa seine Programme so Modular designen, dass man später leicht einen einzelnen Bereich des Programms alleine begutachten kann, ohne gleich einen riesigen Schwanz an anderen Funktionen ständig mitrumschleppen zu müssen - sprich: Debuggen wird umso leichter, je besser man sich auf den Code konzentrieren kann, in dem der Fehler vermutet wird, ohne dass man durchgehend von anderem Code abgelenkt wird. Das entsprechende Stichwort ist <b>strukturierte Programmierung</b>.
+Worauf man immer achten kann ist, wie schwer man sich das Fehlerfinden macht. Muss man älteren Code debuggen, oder den eines anderen Programmierers, so sind Kommentare mit das wertvollste, was es gibt. Andererseits sollte man bei seinem Code auch darauf achten, dass er sich später leicht debuggen lässt, etwa seine Programme so Modular designen, dass man später leicht einen einzelnen Bereich des Programms alleine begutachten kann, ohne gleich einen riesigen Schwanz an anderen Funktionen ständig mitrumschleppen zu müssen - sprich: Debuggen wird umso leichter, je besser man sich auf den Code konzentrieren kann, in dem der Fehler vermutet wird, ohne dass man durchgehend von anderem Code abgelenkt wird. Das entsprechende Stichwort ist '''trukturierte Programmierung'''.
-Daneben sollte man in Funktionen sog. Assertions einfügen. Sie sind Annahmen. Etwa, dass die Funktion niemals mit dem Parameter I < 0 aufgerufen werden darf, oder ihr Ergebnis niemals 0 sein darf, da es dann an anderer Stelle knackt, oder Speicherbereiche überschrieben werden, die eben nicht überschrieben werden sollten. Entsprechende Annahmen kann man mit dem Befehl <b>Assert(Bedingung)</b> in seinen Code einpflegen. Ist die Bedingung nicht erfüllt, wird man darauf aufmerksam gemacht.
+Daneben sollte man in Funktionen sog. Assertions einfügen. Sie sind Annahmen. Etwa, dass die Funktion niemals mit dem Parameter  '''I < 0''' aufgerufen werden darf, oder ihr Ergebnis niemals 0 sein darf, da es dann an anderer Stelle knackt, oder Speicherbereiche überschrieben werden, die eben nicht überschrieben werden sollten. Entsprechende Annahmen kann man mit dem Befehl '''Assert(Bedingung)''' in seinen Code einpflegen. Ist die Bedingung nicht erfüllt, wird man darauf aufmerksam gemacht.
 Hat man das alles gemacht, kann man seine Algorithmen leicht mit Spezialfällen füttern und damit ausprobieren, ob sie auch das richtige Ergebnis liefern. Manchmal hilft mir bereits ein Taschenrechner um die Funktion des Übels aufzuspüren. Manchmal versucht man auch einen Fehler zu finden, in einem Bereich, in dem gar kein Fehler ist. Das passiert leicht, wenn man sich nicht ganz im klaren ist, was genau passiert oder man einfach etwas verwirrt ist. Hier hilft ein kleiner Trick:

@@ Zeile 11: / Zeile 11: @@
 Nun was bringen einem VCS Systeme? Für den einzelnen Hobbyprogrammierer eher unwichtig, für Gruppen allerdings umso wichtiger: Jeder Nutzer kann sich Dateien vom Server laden und den Schreibzugriff für sich reservieren lassen. Wenn er fertig ist, schickt er die veränderte Datei zurück an den Server. Der Server Archiviert die neue Datei. Er überschreibt aber die Datei nicht wild, sondern behält immer eine ganze Reihe an Dateien. Und hier liegt der Vorteil für den Einzelnen: Man kann die unterschiedlichen Dateiversionen mit dem beiliegendem Diff Tool des jeweiligen VCS Systems einfach vergleichen und bekommt je nach System gleich eine hübsche Gegenüberstellung der beiden Versionen aus dem Archiv. Wenn man sich mal etwas Code richtig zerschossen hat, kann man leicht mal eine ältere Version aus dem Archiv nehmen und damit weiterarbeiten.
-<b>Tipp:</b>Man lasse den Server am besten auf einem anderen Rechner laufen, oder die Archivdatenbank zumindest auf einer anderen Platte speichern. Stürzt einem jetzt die Entwicklungsmaschine ab, bekommt man meist weniger Probleme mit Zerschossenen Dateisystemen, Dateien selbst, etc, denn die liegen ja gut geschützt anderswo vergraben. Auto Backups der Archive sind auch zu empfehlen.
+'''Tipp:''' Man lasse den Server am besten auf einem anderen Rechner laufen, oder die Archivdatenbank zumindest auf einer anderen Platte speichern. Stürzt einem jetzt die Entwicklungsmaschine ab, bekommt man meist weniger Probleme mit Zerschossenen Dateisystemen, Dateien selbst, etc, denn die liegen ja gut geschützt anderswo vergraben. Auto Backups der Archive sind auch zu empfehlen.
 == Einführung in den Delphi Debugger ==