[quote=ptk,23.12.2005, 00:21]Naja, der Duden ist für der Perl-Stil wirklich nicht bindend.[/quote]
Nun, zum Teil verstehe ich den Einwand von steffenw.

Oreilly, Programmieren mit Perl, 2. Auflage, Seite 4 ...

"Sprachen wurden von Menschen zum Nutzen von Menschen eingeführt.
Da Perl von einem (frei formuliert) Gelegenheitslinguisten entworfen
wurde, orientiert sich das Design der Sprache an der Vielfältigkeit der
natürlichen Sprache."

Was sich selbstverständlich auch auf die Syntax beziehen sollte.

Aber ...

Seite xx, Vorwort von Larry Wall ...

"Das wichtigste ist vielleicht, dass Sie nicht alles über Perl wissen müssen,
bevor Sie nützliche Programme schreiben können. Sie können bei Perl
ganz klein anfangen. Sie können sozusagen in Perl ->>Babysprache<<
programmieren, und wir versprechen Ihnen, nicht zu lachen. Um genauer
zu sein, wir versprechen, nicht mehr zu lachen, als wir über etwas
schmunzeln würden, das mit einer Kindern eigenen Kreativität erdacht wurde.
Viele Ideen von Perl sind bei natürlichen Sprachen geborgt. Eine der
besten Ideen ist, dass es in Ordnung geht, nur eine Teilmenge der Sprache
zu verwenden, solange der gewünschte Effekt erzielt werden kann. In der
Perl -Kultur ist jeder Leistungsstand akzeptabel. Wir werden Ihnen nicht
die Sprachpolizei auf den Hals hetzen. Ein Perl-Skript ist >>richtig<<,
wenn es seine Aufgabe erfüllt, bevor Ihr Boss Sie feuert."

Wieso, bei "perltidy -ce" kommt doch fast das gleiche heraus. Nur die Ausrichtung geht verloren.

ich benutz nur perltidy -b

@oli: schon, aber als "erwachsener" ist man verpflichtet, "babies" besseres sprechen beizubringen! :)

[quote=esskar,23.12.2005, 02:22]@opi: schon, aber als "erwachsener" ist man verpflichtet, "babies" besseres sprechen beizubringen! :)[/quote]
hehe :)

dazu habe ich noch ein Sprüchlein von Larry Wall parat ...

"Im Augenblick genügt es, wenn Sie sich merken, dass Perl genau wie ein
guter Zuhörer versucht zu verstehen, was Sie sagen. Perl arbeitet sehr
hart daran, seinen Teil der Vereinbarung einzuhalten. Sagen Sie einfach,
was Sie meinen, und Perl wird es üblicherweise verstehen. (Wenn Sie nicht
gerade Unsinn reden - denn natürlich versteht der Perl-Parser Perl
wesentlich besser als Englisch oder Suaheli.)"

oder Babysprache. Aber aus dem Alter bin ich schon lange raus ...
das behaupte ich jetzt einfach mal ;)

Gute Kommentare, Steffen.

[quote=steffenw,21.12.2005, 20:26]
ist für mich übertrieben gequotet. {} quotet schon Hashkeys, man muß also nicht erst mit '...' die Evaluierung anwerfen.
[/quote]
Und das "fat comma" (=>) quotet auch den Ausdruck links von sich, sofern er die Form eines Identifiers hat, also kann man auch das 'passwd' ohne Anfuehrungszeichen schreiben. (Die Einschraenkung mit dem Identifier gilt uebrigens auch fuer das Quoten innerhalb von {}.)

Es ist aber zugegebenermassen Uebungssache, bis man im Gefuehl hat, was man da quoten muss und was nicht. In der Praxis kann man sehr viele Anfuehrungszeichen weglassen, weil Hashkeys sehr oft nur aus Buchstaben bestehen.

Quote

Code: (dl )

print ' ' x 2 . "$key" . ' ' x (30-length($key)) . "$value\n";

print erwartet nicht einen Scalar, es erwartet Listen. Du kannst also print die einelnen Elemente durch Komma getrennt hinwerfen und mußt sie nicht erst vorher zusammenverketten. Wie das print dann optimiert, ... ist print's Sache.

In diesem Fall waere aber ein printf sowieso deutlich einfacher und uebersichtlicher:

Quote

Code: (dl )

return undef;

Das ist doppelt. return; ohne Argument ist richtig und undef; auch, weil es der zuletzt evaluierte Wert ist und somit sowieso zurückgegeben wird. Beides zusammen bremst nur.

Vorsicht, da besteht ein Unterschied zwischen return undef und return. Beides ist zwar gleichwertig, wenn die Funktion im skalaren Kontext aufgerufen wird, aber im Listenkontext liefert die erste Variante ein (skalares) undef, die zweite aber eine leere Liste zurueck.

Ein print meinesub() z.B. gaebe (unter use warnings) eine Warnung aus, wenn meinesub() mit return undef endet, mit einem einfachen return kaeme gar nichts.

Es kommt also darauf an, welches Verhalten erwuenscht ist.

[quote=Dubu,23.12.2005, 09:44]Und das "fat comma" (=>) quotet auch den Ausdruck links von sich, sofern er die Form eines Identifiers hat, also kann man auch das 'passwd' ohne Anfuehrungszeichen schreiben. (Die Einschraenkung mit dem Identifier gilt uebrigens auch fuer das Quoten innerhalb von {}.)

Es ist aber zugegebenermassen Uebungssache, bis man im Gefuehl hat, was man da quoten muss und was nicht. In der Praxis kann man sehr viele Anfuehrungszeichen weglassen, weil Hashkeys sehr oft nur aus Buchstaben bestehen.[/quote]
Das geht auch, wenn Zahlen oder _ und noch andere Zeichen enthalten sind... Also nicht nur Buchstaben...

[quote=Dubu,23.12.2005, 09:44]ist für mich übertrieben gequotet. {} quotet schon Hashkeys, man muß also nicht erst mit '...' die Evaluierung anwerfen.[/quote]
aber leider war meine Frage noch nicht beantwortet, wie es mit der
Kompilierung ausschaut... ob sie durchs Quoting schneller wird oder nicht...

[quote=opi,23.12.2005, 10:00][quote=Dubu,23.12.2005, 09:44]ist für mich übertrieben gequotet. {} quotet schon Hashkeys, man muß also nicht erst mit '...' die Evaluierung anwerfen.[/quote]
aber leider war meine Frage noch nicht beantwortet, wie es mit der
Kompilierung ausschaut... ob sie durchs Quoting schneller wird oder nicht...[/quote]
Wenn ich's richtig verstehe ist das Zitat von Steffen, nicht von Dubu...

Der Kompilierung ist das ganz egal, weil es schon vorher wegoptimiert* wird.

Übringens sollte man in Perl nicht generell auf Geschwindigkeit, sondern auf Verständlichkeit programmieren.
Perl selbst kümmert sich derart viel ums optimieren, daß der Schuß sonst gerne auch nach hinten los geht.

Zeit kann man imho sehr viel besser sparen, wenn der Kram gut wartbar und wiederverwendbar wird. Wenn man dann etwas zeitkritisches hat, und der Code zu langsam ist, dann kann man immer noch
- schneller Hardware kaufen (die günstigste Methode)
- den Code optimieren
- bei Perlmonks meckern, daß es zu langsam läuft
- London.pm erzählen, daß es ein T-Shirt für den gibt, der bis Ostern die Aufgabe am schnellsten hin kriegt
- in C oder Assembler schreiben
- einen Fachmenschen beauftragen
- bessere Hardware entwickeln

* bzw. in diesem Fall dazuoptimiert. Laß es doch mal mit B::Deparse (perl -MO::Deparse) ausgeben.\n\n

<!--EDIT|Relais|1135332650-->

Den Tipp mit London.pm werde ich mir merken *g*