Matthias schrieb den sehr empfehlenswerten Tipp:
Schreib deinen Code, als würde er auf's CPAN kommen
Dem kann ich mich nur anschließen. Auch wenn Code nur intern zum Einsatz kommt (was in der Praxis die Regel ist), sollte er stets nach den CPAN-Regeln und mit Hilfe der üblichen Tools erstellt werden. Dazu gehören beispielsweise Module::Starter (und Plugins, ich verwende zum Beispiel Module::Starter::PBP und Module::Starter::Smart; Module::Setup sieht aber auch interessant aus), Module::Build und die üblichen Test-Tools.
Zusätzlich sollte man aber auch immer die folgende Regel aus Damian Conways Perl Best Practices (siehe auch: Tipps für Perl-Bücher; Amazon-Direkt-Link zu PBP) beachten:
Codieren Sie immer so, als wäre der Typ, der den Code pflegen muss, ein gewaltbereiter Pshychopath, der weiß, wo Sie wohnen.
Und dem möchte ich noch hinzufügen: es handelt sich bei dem gewaltbereiten Psychopathen um den mit der Kettensäge ...
Um die Gefahr ein wenig zu reduzieren gibt es natürlich auch ein passendes Perl-Werkzeug: Perl::Critic und Test::Perl::Critic. Perl::Critic wacht dann im Rahmen der üblichen Test-Suite bei einem ./Build test darüber, dass der Code halbwegs sauber ist. Der Schwellwert (über den Parameter severity gesteuert) steht standardmäßig auf dem schwächsten Level 5, ich setze den auf jeden Fall auf 3 herab, so dass mehr Konstrukte angemeckert werden. Mit verbose=11 lassen sich ausführliche Meldungen erzwingen. Außerdem schalte ich ein paar Tests ab: RequirePodSections verlangt mir bei Kunden-Projekten zu viele bzw. die falschen POD-Sektionen, und RequirePodAtEnd verbietet POD direkt bei den Unterfunktionen, ich habe die Doku aber lieber da als am Ende vom Code.
Auf jeden Fall lassen sich so einige unsichere und gefährliche Konstrukte ausschließen. Perl::Critic meckert zum Beispiel auch, wenn einzelne Unterfunktionen zu komplex (und damit zu schwer verständlich) oder Blöcke zu tief verschachtelt sind. So kann man nicht nur die Kollegen sondern auch sich selbst ganz gut zwingen, weniger komplizierten Code zu schreiben: so ist dann zum Beispiel ab 20 if-Abfragen und ähnlichem pro Unterfunktion Schluss. Denn, man denke an den Psychopathen mit der Kettensäge ...
Alles schön und gut, aber ich werde nicht für schönen Code bezahlt. "Tut mir leid Chef, dauert noch eine Woche länger, mein Programm funktioniert hat aber zu viele if-Blöcke und ist nicht schön genug!" geht eben nicht.
Ich muss fertig werden, denn die nächste Aufgabe wartet schon. Die reine Lehre ist da fehl am Platze.
Es ist ein Trugschluss zu glauben, dass man für sauberen Code mehr Entwicklungszeit benötigt. Das Gegenteil ist der Fall: Änderungen und Erweiterungen sind weitaus schneller integriert, auch solche die im ganz normalen ersten Entwicklungszyklus auftreten. Bugs werden schneller gefunden und das Testen erleichtert. Natürlich kann man jedes mal die ganze Applikation durchlaufen lassen, um eine bestimmte Stelle zu testen. Viel einfacher und zeitsparender ist es aber, für die einzelnen Module/Klassen und Funktionen/Methoden Tests zu schreiben, die sie erstmal einzeln und dann im Zusammenspiel testen.
Auf den ersten Blick mag das zwar mehr Arbeit bedeuten, in der Praxis sieht es aber ganz anders aus. Man muss sich nur dazu überwinden, die alten Gewohnheiten zu überdenken.
Systeme, die auf hastig vor dem Abgabeschluss zusammengeschmierten Code basieren, administriere ich seit acht Jahren. Zwischenergebnis: Der Code mag vielleicht die Endabnahme überleben, keineswegs jedoch den Betrieb. Die Tatsache, dass ein Programm auf dem Entwicklernotebook mit zehn Datensätzen und einem JMeter-Lauf geschmeidig läuft, sagt nichts über den Betrieb auf einem Vier-Knoten-Cluster mit angeschlossenem Oracle-RAC und davor geschalteten Apache-Proxies, einer Millionen Datensätzen und zehn gleichzeitigen Nutzern aus. Selbst wenn in den ersten Wochen Betrieb nichts passiert, irgendwann treten Fehler auf, und dann sollte sich besser jemand den Code ansehen. Natürlich ist der Schmierulant, der Version 1.0 augeschieden hat, längst in ein anderes Projekt abgetaucht, so dass sein Nachfolger verzweifelt versuchen darf, mit einem nur bei bestem Willen mit Dokumentation zu verwechselnden Text durch das Gehuddel zu steigen. Weil das Ganze natürlich länger dauert als geplant, fährt inzwischen die Produktion völlig gegen die Wand, der Kunde tobt, im Heise-Forum zerreißen sich Teenager mit Computerviertelwissen das Maul, und die Verluste erreichen den fünfstelligen Bereich. Um wenigstens rudimentär wieder ans Laufen zu kommen, werden in aller Eile und mit viel Geld der Speicher erweitert, die Applikation auf ein Quarantänesystem umgezogen und Sonderregeln in den Proxy eingepflegt - und das alles nur, weil alles schnell fertig werden musste.