Use Warnings In Perl? Nie!

Das Perl-Pragma "use warnings" nervt ungemein. Trotzdem gehört es zum Grundgerüst vieler Perl-Entwickler, die nicht merken, wie sehr sie damit ihre User und die User ihrer User drangsalieren und in die Rolle unfreiwilliger Betatester zwingen.

Moment mal! Aber in C ist es doch anerkannte Praxis, möglichst alle nicht esoterischen Warnungen zu aktivieren. Weshalb soll es dann in Perl schlecht sein?

Es gibt einen wichtigen Unterschied. C ist eine kompilierte Sprache, und C-Warnungen sind daher immer Kompilierzeit-Warnungen. Perl ist eine interpretierte Sprache, und wenngleich Perl auch zwischen Kompilierzeit- und Laufzeitwarnungen unterscheidet, so ist diese Unterscheidung aus Nutzersicht künstlich und nicht nachvollziehbar. Kompilierzeit-Warnungen und Laufzeit-Warnungen sehen für Nutzer immer gleich aus, nämlich wie Laufzeitwarnungen. Sie nerven, sind ein Indiz für Entwickler-Ignoranz, so wie Stack-Traces in Java oder anderen Sprachen, die dem schlechten Beispiel von Java gefolgt sind.

Zielgruppe automatisch generierter Warnungen ist in erster Linie der Autor der Software. Nutzer der Software, und erst recht Nutzer der Nutzer der Software sollten damit nicht behelligt werden. Sie können Warnungen anschalten, wenn sie das wollen, aber sollten nicht dazu gezwungen werden.

Aber entgehen ihnen dann nicht wichtige Informationen? Besonders, wenn sie selber Entwickler sind und eine Bibliothek benutzen? Nicht wirklich. Ich habe mindestens eine Million Zeilen Perl-Code geschrieben, und habe noch nie ein Problem in fremden Modulen gefunden, weil dort Warnungen aktiviert waren. Und ehrlich gesagt sind die meisten Perl-Warnungen ziemlich nutzlos ("Wide character in ..." oder ähnlicher Unfug).

Na, gut, aber mein Supermodul ist schließlich freie Software. Das Mindeste, was die Nutzer tun können, ist ein bisschen Unterstützung beim Aufspüren von Problemen im Code, oder? Nein! Wer so denkt, sollte seine Software dann doch lieber verkaufen. Das "Frei" in freier Software steht für Freiheit, nicht für Freibier. Wer Hilfe von seinen Usern will, muss darum bitten oder dafür bezahlen.

Das kann aber alles nicht stimmen, weil "perldoc warnings" doch explizit darauf hinweist, dass "use warnings" viel besser ist als die Kommandozeilenoption "-w". Die Wirkung von "use warnings" ist auf den jeweiligen Block beschränkt und kann sich nie über Dateigrenzen hinweg entfalten. Na und? Es fehlt aber der Hinweis, dass von "use warnings" erzeugte Warnungen vom Benutzer nicht abgeschaltet werden können, jedenfalls nicht auf einfache Weise.

Und genau deshalb sollte man als Modulautor in seiner eigenen Entwicklungsumgebung Warnungen mit der Kommandozeilenoption "-w" aktivieren. Entwickelt man eine Webapplikation, sollte man stattdessen in der Webserver-Konfiguration die Umgebungsvariable PERL5OPT auf "-w" setzen. Paket-Maintainer sollten dasselbe tun, Endnutzer nur, wenn sie Lust darauf haben.

Folge ist, dass Warnungen global aktiviert sind, und nur für die vorgesehene Zielgruppe sichtbar sind, nämlich für den Autor der Software, andere Profis und interessierte User. Es ist dann deren Bier, die wenigen wichtigen Warnungen aus dem Rauschen herauszufiltern. Die User dagegen werden dankbar sein, dass ihre Logfiles nicht weiter mit ungefragten Debug-Informationen für anderer Leute Code zugemüllt werden.