[quote=pq,22.09.2005, 21:25]es geht hier nicht um das, was strat am besten findet, sondern was sich als gängige und lesbare praxis bei den meisten perlern durchgesetzt hat.[/quote]
ich habe auch ein paar komische coding-style-eigenheiten, bei denen sich vermutlich manch anderen leuten die haare aufstellen. Wenn ich solche Sachen bei Kursen verwende, weise ich darauf hin, dass viele Leute einen anderen Weg bevorzugen, oder welche Gefahren mein Weg bietet, und dass jeder seinen eigenen Weg finden sollte.

Als Beispiel rufe ich Subroutinen, die ich selbst geschrieben habe, immer in der Form &Subroutine(...) auf, fremde hingegen immer Subroutine(...) bzw. subroutine(...). Das hat in meinen Augen folgende Vorteile:
1. Ich sehe sofort, ob eine Subroutine von mir geschrieben wurde oder jemand anderem (spielt zwar meist keine so grosse Rolle, da ich so gut wie nie [s]Namespace Pollution[/s] den Exporter benuetze, ausser vielleicht fuer irgendwelche Konstanten)
2. Da ich so gut wie nie Prototypen verwende, stoert das & auch nicht (& deaktiviert naemlich Prototypen)
3. Ich finde es logischer, analog zu $scalar, @array, %hash, &Subroutine

Gefaehrlich kann das hingegen sein, wenn man keine Parameter uebergibt und dann die Klammern weglaesst, z.B. &Subroutine. Da wird naemlich automatisch @_ der aktuellen Subroutine uebergeben, und das kann u.U. Nebeneffekte haben (ein prominentes Beispiel gab es unlaengst hier im Forum)

oder: ... or die ...
das verwende ich so gut wie nie; ich bevorzuge unless (....) { die... } , obwohl or-die perliger ist. aber ich schreibe meist groessere sachen (>10000 Zeilen), und da uebersieht man ein or-die oft schneller als einen eigenen unless-block. Aus Gruenden der politischen Korrektheit moechte ich jedoch ausdruecklich betonen , dass ich aus humanitaeren Gruenden so weit wie moeglich versuche, auf "die" zu verzichten, und - wenn moeglich - das Problem gleich zu beheben.\n\n

<!--EDIT|Strat|1127420135-->