2013-08-07T21:49:11 sri

2013-08-07T16:29:04 hlubenow

Was schlechter Code ist, bestimme (für mich selbst) nur ich und der Interpreter, sonst niemand. Wenn's keinen Fehler wirft und das tut, was es soll, ist es schonmal ok.

Das geht solange gut bis du mit anderen zusammen arbeiten musst. Wenn ich idiomatisches Perl empfehle, dann denke ich auch immer an die Jenigen die vielliecht in zukunft einmal hinter dir aufraeumen muessen.

Ok, das sehe ich wiederum ein: Ein Arbeitgeber, der mich bezahlt, dürfte mir natürlich Anweisungen bzgl. des Codes geben.
Trotzdem denke ich, daß jedenfalls gerade von Perl eine besondere Toleranz in dieser Frage besteht. Deswegen ja auch das TMTOWTDI. Und auch "perldoc perlstyle" schränkt einen weit weniger ein als Style-Guides in anderen Sprachen.
Diese Toleranz kommt auch in diesem bekannten Zitat zum Ausdruck:

Quote

To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them.

Perl ist besonders gut für kurze Skripte, in denen man sich viel Freiheit erlauben kann und will.
Bei großen Projekten mit einer Vielzahl von Programmierern halten es manche für weniger geeignet. Vielleicht gerade deswegen. Aber man kann auch solche Projekte umsetzen. Dann muß man sich aber wahrscheinlich doch wieder auf einen Code-Standard einigen, und etwa Module wie 'Perl::Critic' einsetzen.
Es sind wohl zwei verschiedene Situationen.