BriansGuideToSolvingAnyPerlProblem

Dies ist (wird) eine Übersetzung vom Perlmonks-Artikel http://www.perlmonks.org/?node_id=376075 von brian d foy.

SYNOPSIS

Folge diesem Leitfaden und bleib cool.

BESCHREIBUNG

Meine Philosophie des Debuggens.

Ich glaube an drei Dinge:

• Es ist nicht persönlich.

Vergiss Code-Eigentum. Du magst dich selbst als Künstler sehen, aber sogar die alten Meister produzieren eine Menge Mist. Eines jeden Code ist Mist, d.h. mein Code ist Mist und deiner auch. Lerne das zu lieben. Wenn Du ein Problem hast, sollte Dein erster Gedanke sein "Es stimmt was nicht mit meinem Code". D.h. man sollte nicht zuerst perl verantwortlich machen. Es ist nicht persönlich.

Vergiss, wie Du Dinge angehst. Wenn es funktionieren würde, würdest Du das hier nicht lesen. Das ist nichts schlechtes. Es ist nur Zeit, sich weiterzuentwickeln. Wir haben das alle schon hinteruns.

• Persönliche Verantwortlichkeit

Wenn Du ein Problem mit einem Skript hast, ist es genau das - Dein Problem. Du solltest soviel wie möglich tun, um es selbst zu lösen. Jeder sonst hat seine eigenen Skipte und somit seine eigenen Probleme. Mach Deine Hausaufgaben und tu Dein bestes, bevor Du jemanden anderen damit behelligst. Wenn Du wirklich alles in diesem Leitfaden ohne Erfolg ausprobiert hast, dann ist es Zeit, sich bei jemandem Hilfe zu holen.

• Verändere Deine Herangehensweise

Repariere Dinge, so dass Du das selbe Problem nicht nochmal bekommst. Das Problem ist vermutlich, wie Du codest, nicht was. Die Veränderung wird Dir das Leben leichter machen. Versuch nicht, Perl an Dich anzupassen, das wird nicht funktionieren. Pass Dich an Perl an. Es ist schließlich nur eine Sprache, keine Lebenseinstellung.

Meine Methode

Kompiliert Dein Skript mit strict?

Wenn Du noch kein strict benutzt, fang jetzt damit an. Perl Gurus sind Gurus, weil sie strict benutzen und das ihnen Zeit gibt, um andere Probleme zu lösen, neue Dinge zu lernen und funktionierende Module auf CPAN zu laden.

strict kannst Du mit dem strict -Pragma anschalten:

 
  use strict; 

Auf der Kommandozeile geht das mit dem -M Switch:

  perl -Mstrict script.pl 

Zuerst mag es nerven, aber nach ein paar Wochen damit schreibst Du besseren Code, verschwendest weniger Zeit an simple Fehler und wirst diesen Leitfaden vermutlich nicht brauchen.

Was ist die Warnung?

Perl kann Dich vor vielen fragwürdigen Konstrukten warnen. Schalte warnings ein und lass Dir helfen.

Das geht mit dem -w Switch sowohl in der Shebang:

  #!/usr/bin/perl -w

als auch auf der Kommandozeile:

  perl -w script.pl

Du kannst lexikalische Warnungen mit jeder Menge interessanter Features benutzen. Siehe warnings

  use warnings;

Wenn Du eine Warnung nicht verstehst, kannst Du sie in perldiag nachschlagen oder das diagnostics -Pragma benutzen:

        use diagnostics;

Löse das erste Problem zuerst!

Wenn Du Warnungen oder Fehler von Perl bekommst, löse das Problem der ersten Meldung und schau dann, ob die anderen Meldungen immer noch auftauchen. Sie könnten auch Artefakte der ersten Meldung gewesen sein.

Schau Dir auch den Code vor der Zeilennummer aus der Meldung an!

Perl warnt Dich, wenn es brenzlig wird und nicht vorher. Zum Zeitpunkt, an dem es brenzlig wird, ist das Problem schon aufgetaucht und die Zeilennummer befindet sich nach dem Problem. Schau also auf ein paar Zeilen über der gemeldeten Zeile.

Ist der Wert genau das, was ich glaube?

Rate nicht! Prüfe den Wert tatsächlich, bevor Du ihn in einem Statement benutzen willst. Der beste Debugger des Universums ist print.

    print STDERR "The value is ]$value]\n";

Ich schließe den Wert in Klammern ein, damit ich Leerzeichen oder Zeilenumbrüche nicht übersehe.

Wenn ich etwas anderes als einen Scalar habe, benutze ich Data::Dumper um die Datenstruktur auszugeben.

     
    require Data::Dumper;

    print STDERR "The hash is ", Data::Dumper::Dumper( \%hash ), "\n";

Sollte der Wert nicht dem entsprechen, was Du Dir vorstellst, geh ein paar Schritte zurück und versuche es noch einmal! Tu dies so lange, bis Du den Punkt findest an dem der Wert nicht mehr das ist was er sein sollte.

Du kannst auch Perl's integrierten Debugger mit dem -d Schalter benutzen. Siehe perldebug für Details.

    perl -d script.pl

Du kannst auch andere Debugger oder Entwicklungsumgebungen benutzen, wie ptkdb (ein graphischer Debugger, auf Tk basierend), Komodo (ActiveStates? Perl IDE, auf Mozilla basierend) oder Affrus auf MacOS? X.

Benutzt Du die Funktion richtig?

Ich programmiere schon eine ganze weile Perl und dennoch schaue ich fast jeden Tag auf perlfunc nach. Manche Dinge kann ich mir einfach nicht behalten, und manchmal bin ich so übermüdet, dass mir alle Sinne schwinden und ich mich wundere, weswegen sprintf nichts auf dem Bildschirm ausgibt.

Du kannst mit dem perldoc -Kommando und seinem Schalter -f eine bestimmte Funktion nachschlagen.

  perldoc -f function_name

Wenn Du ein Modul benutzt, lies die Dokumentation um sicher zu stellen, dass du es richtig benutzt. Du kannst die Doukumentation des Modul via perldoc nachlesen.

  perldoc Module::Name

Verwendest Du die richtige Variable?

Ich schaue auch regelmäßig in perlvar nach. Nun, das stimmt eigentlich nicht, denn ich finde, dass "Perl kurz&gut" ("Perl Pocket Reference") einfacher zu benutzen ist.

Verwendest Du die richtige Version eines Moduls?

Bei manchen Modulen hat sich das Verhalten zwischen Versionsnummern geändert. Hast Du wirklich die Version installiert, die Du erwartest? Du kannst die Versionsnummer mit einem einfachen Perl-Einzeiler überprüfen:

  perl -MModule::Name -le 'print Module::Name->VERSION';

Wenn bei Dir die meiste Dokumentation aus einer anderen Quelle als der lokalen Maschine stammt (z.B. http://www.perldoc.com/ oder http://search.cpan.org/), ist es wahrscheinlicher, dass Du auf Abweichungen in der Dokumentation stößt.

Hast Du ein kleines Testprogramm zu Deinem Problem geschrieben?

Wenn Du etwas Neues ausprobierst oder wenn Du denkst, dass sich ein Code-Abschnitt eigenartig verhält, schreibe das kürzestmögliche Programm, das genau diese Aufgabe erledigt. Damit schließt Du die meisten anderen Faktoren aus. Wenn das kleine Testprogramm das tut, was Du erwarten würdest, dann steckt das Problem wahrscheinlich nicht in diesem Programmteil. Wenn das Programm sich nicht erwartungsgemäß verhält, dann hast Du vielleicht Dein Problem gefunden.

Hast Du die Umgebungsvariablen überprüft?

Einige Dinge hängen von bestimmten Umgebungsvariablen ab. Bist Du sicher, dass sie richtig gesetzt sind? Ist Deine Umgebung dieselbe, die das Programm zu seiner Laufzeit sehen wird? Beachte, dass Programme, die als CGI-Skript oder Cron-Job laufen werden, andere Umgebungsvariablen mitbekommen, als solche, die in Deiner Shell laufen. Das gilt insbesondere für Programme, die auf anderen Maschinen laufen werden.

Perl macht die Umgebungsvariablen über %ENV zugänglich. Wenn Du eine Umgebungsvariable verwenden willst, setze einen Defaultwert für den Fall, dass sie nicht gesetzt ist, selbst wenn Du nur testen willst.

Sollte es immer noch Probleme geben, lass Dir die Umgebungsvariablen ausgeben:

    require Data::Dumper;

    print STDERR Data::Dumper::Dumper( \%ENV );

Hast Du Google befragt?

Das Problem, auf das Du gestoßen bist, haben wahrscheinlich schon andere Leute vor Dir gehabt. Schau nach, ob jemand dazu etwas in der Usenet-Gruppe comp.lang.perl.misc geschrieben hat. Google Groups kann dabei behilflich sein (http://groups.google.com). Der Unterschied zwischen denjenigen, die im Usenet Fragen stellen und denjenigen, die sie beantworten können, ist die Fähigkeit, Google Groups zu bedienen.

Hast Du die Ausführungszeit Deiner Anwendung gemessen?

Wenn Du die langsamen Teile eines Programm finden willst, solltest Du detaillierte Geschwindigkeitsmessungen durchführen. Lass Devel::SmallProf dabei die Drecksarbeit erledigen. Es zählt für jede Codezeile, wie oft sie von Perl abgearbeitet wird und wie lange die Ausführung dauert, und gibt eine hübsche Zusammenfassung aus.

Welcher Test schlägt fehl?

Gibt es eine Testsuite zu Deinem Programm? Welcher Test schlägt fehl? Weil jeder Test nur einen kleinen Teil des Codes ausführt, müsstest Du in der lage sein, den Fehler schnell zu isolieren.

Wenn Du keine Testsuite hast, wäre es vielleicht eine gute Idee, eine zu erstellen. Wenn es sich nur um ein kleines Wegwerfskript handelt, würde ich Dich nicht dazu zwingen wollen, eine Testsuite zu schreiben, aber bei allem, was größer ist, können Testskripte von Nutzen sein. Test::Harness macht die Arbeit mit Testskripten so einfach, dass es keine Ausrede gibt, darauf zu verzichten. Wenn Du glaubst, dafür keine Zeit übrig zu haben, verschwendest Du vielleicht zuviel Zeit damit, Skripte ohne Tests zu debuggen. MakeMaker? ist nicht nur sinnvoll für Module.

Hast Du mit Deinem Teddybär gesprochen?

Erkläre das Problem. Sprich es tatsächlich laut hörbar aus.

Ich hatte ein paar Jahre lang das Glück, mit einem wirklich guten Programmierer zusammenzuarbeiten, der beinahe alle Probleme lösen konnte. Immer wenn ich nicht mehr weiterwusste, lief ich zu seinem Schreibtisch und erzählte ihm von meinem Problem. Meistens kam ich nicht einmal bis zum dritten Satz, ohne vorher zu sagen: ``Vergiss es, ich hab's!'' Er irrte sich auch fast nie.

Weil das wahrscheinlich ziemlich oft vorkommen wird, empfehle ich ein Kuscheltier als Perl-Therapeuten, damit Du deinen Kollegen nicht auf den Wecker gehst. Ich habe einen kleinen Teddybären, der auf meinem Schreibtisch sitzt und dem ich von meinen Problemen erzähle. Meine Frau bemerkt es mittlerweile nicht einmal mehr, wenn ich anfange, Selbstgespräche zu führen.

Sieht das Problem auf Papier anders aus?

Du hast lange konzentriert auf einen Bildschirm gestarrt. Vielleicht gibt ein anderes Medium Dir einen neuen Blickwinkel. Versuche es mit einem Ausdruck Deines Programms.

Hast Du ferngesehen?

Das meine ich ernst. Vielleicht ist Fernsehen nicht Dein Ding, dann tue irgendetwas anderes. Mache eine Pause, denke eine Weile lang nicht über das Problem nach und lass einfach Deinen Geist entspannen. Wenn du später zu Deinem Problem zurückkehrst, wird Dir die Lösung vielleicht sofort klar.

Stehst Du Dir selbst im Weg?

Wenn Du bis hierher gekommen bist, hat das Problem möglicherweise einen psychischen Kern. Vielleicht hängst Du an einem Teil des Codes und möchtest ihn daher nicht ändern oder wegwerfen. Vielleicht denkst Du auch einfach, dass Du im Recht bist. Wenn Dir das passiert, dann hast Du die wahrscheinlichste Fehlerquelle nicht berücksichtigt -- Dich selbst. Überprüfe alles, verwirf keinen Hinweis.

-- TinaMueller - 09 Jan 2008 -- StefanPomerig - [small part] 17 Jan 2008 -- HilkoBengen - 03 Jul 2008