Erfahrungen beim Programmieren

Beim Programmieren kann man viele schöne Erfahrungen machen, zum Beispiel mit Fehlern. Fehler sind dabei nämlich etwas Alltägliches. Anders als beim Fehler im Deutschaufsatz merkt man aber gleich, dass etwas falsch ist, und das ganz ohne den Hinweis eines Lehrers: Der Computer weigert sich zum Beispiel, einen Programmtext zu akzeptieren, weil man irgendeinen syntaktischen (=grammatischen) Fehler gemacht hat. Den muss man dann suchen und verbessern, sonst geht es nicht weiter. Das halte ich für eine lehrreiche Erfahrung.

Noch spannender sind die semantischen Fehler: Das Programm läuft zwar, aber es tut einfach nicht das, was es soll. Das ärgert einen. Die unmittelbare Reaktion ist: der Computer hat einen Fehler gemacht, Tatsächlich muss man aber akzeptieren, dass – in den in der Schule auftretenden Fällen jedenfalls – das Programm genau das macht, was man ihm gesagt hat. Nur hat man ihm einfach das Falsche gesagt; es ist ein Fehler des Programmierers und nicht des Computers.

Erst neulich: Da war so eine Stelle, eingebettet in viele ähnliche Stellen, da hieß es quasi

wenn (a<0 oder b>0) dann:
    tue Folgendes

Das Programm hat jenes eher komplizierte Folgende aber nicht. Erster Schritt: Überprüfen, ob die beiden Bedingungen tatsächlich erfüllt sind. “Doch, sind sie,” versicherte der Schüler. “Kann gar nicht anders sein. Das muss so sein, weil sonst hätte ja gar nicht…” Der Erklärung habe ich gar nicht zugehört. Warum das logisch gar nicht sein kann, dass die Bedingungen nicht erfüllt sind, ist mir egal, solange sich einfach überprüfen lässt, welchen Wert a und b zu diesem Zeitpunkt im Programmablauf haben, also in welchem Zustand sich das Programm zu diesem Zeitpunkt befinden. Manche Entwicklungsumgebungen bringen dazu ein Debugger genanntes Werkzeug mit, aber man kann sich auch einfach den Wert vona und b ausdrucken lassen, kurz bevor sie abgefragt werden.

Und was nicht sein konnte, war dann doch so. Jetzt muss man weiter suchen, wieso a oder b den Wert haben, den sie nicht haben sollen. Hypothesen aufstellen, überprüfen, ausbessern.

5 Antworten auf „Erfahrungen beim Programmieren“

  1. Das mit den Fehlern beim Programmieren ist eine wirklich spannende Sache. Ich habe es selbst erlebt, als ich zur Softwareentwicklerin umgeschult habe vor vielen Jahren. Der Computer hat mich regelrecht erzogen und das völlig ohne “pädagogischen Anspruch”, erhobenen Zeigefinger, menschliche Rechthaberei oder persönliche Machtgeschichten. So habe ich damals z.B. sehr sorgfältiges Arbeiten gelernt: Das “Ding” tat einfach nicht das, was es sollte, wenn ich einen Fehler gemacht hatte – und das Problem lag auf MEINER Seite.
    Für Schüler ist das sicher auch eine lehrreiche Erfahrung, dass sie eigene Fehler beim Programmieren niemand anderem in die Schuhe schieben können, so wie das oft bei schlechten Noten passiert: “Der hat mir nur die 5 gegeben, weil der mich nicht ausstehen kann.” Dieser Projektionsmechanismus funktioniert beim Programmieren einfach nicht: Man ist auf sich selbst verwiesen.
    Der Computer kann ein genialer Pädagoge sein …

  2. Als jemand der jeden Tag Code schreibt kann ich nur zustimmen (und den Hut ziehen vor den Programmierern vergangener Tage, die viel besseren Code schreiben mussten, mit weniger Korrekturen, z.B. auf Lochstreifen.)

    Ich hab mir damals eine Liste gemacht, mit häufigen Fehlern, und woran man sie merken könnte. Manche merkt ein Compiler, manche nicht. Mal schaun ob ich die noch wo finde…

  3. Ein Debugger ist ein tolles Werkzeug, um einem Programm bei der Ausführung zuzuschauen. Ich sollte den viel früher im Unterricht thematisieren.

  4. DIe häufigsten Fehler bei meinen Schülern dürften sein: Null pointer, mit großem Abstand. Dann vielleicht Array out of bounds. Und dann das Deklarieren und Initialisieren von Variablen, ob als Attribut oder Parameter.

    Debugger: Den setze ich auch noch viel zu wenig ein. BlueJ, eine bekannte schulische Entwicklungsumgebung für Java, hat einen eingebaut, den müsste ich mehr nutzen.

  5. NullPointer sind nicht nur bei Anfängern ein häufiges Problem. Man kann sie häufig umgehen, wenn die Objekte nach Aufruf des Konstruktors immer vollständig initialisiert sind. Unter Umständen muss man sich dann Gedanken darüber machen, wie man das Nichts durch spezielle Instanzen besser ausdrücken kann als durch eine Null-Referenz.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.