Opened by bloonix at 2005-12-19 02:24
User since
2003-08-15
692 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2003-08-15
692 Artikel
BenutzerIn
use warnings und use strict ist Pflicht!!! Daran rüttelt hier keiner.
Das sorgt schon mal dafür, daß Perl dann verlangt, daß Du Deinen Code verstehst und er nicht nur einfach funktioniert. Das könnte nach der nächsten Erweiterung ja schon ganz anders aussehen. Es ist auch so, daß man den Block { no strict '???'; spezielleAnweisung; } so kurz wie möglich halten sollte. Aber wenn man genau weiß, was man tun will, ist das auch in Ordnung. Strict soll einem helfen, aber niemals ein Hindernis sein. Sonst gäbe es die no ...-Anweisungen nicht.
Schreibst Du ähnlichen Code, der sehr gleichartige Konstrukte enthält, so wie Du das gerade gemacht hast, dann schreit das regelrecht nach einer Schleife/Aliasing. Blöd war nur die sub, stimmt schon, nur weil auch da der Name auf's Auge paßte, ging das gut mit symbolischen Referenzen. Man hätte auch einen helfenden Hash einsetzen können, um "no strict" zu verhindern, siehe:
Arbeite erst dann mit Referenzen, wenn sie nötig sind, nicht gleich mal so. Verkompliziere Dein Programm nicht unnötig.
Ja die Listenübergabe mit den Namen schränkt natürlich ein. Aber sie verhindert nichts, denn Du kannst sie aufbohren. Wenn ein Scalar nicht reicht, baue da später an die Stelle eine Array- oder Hash-Referenz ein und schon kannst Du mehr als einen Wert einbauen, "ref $????" hilft dann bei der Erkennung, was da angeflattert kommt. Also ist so schon mal nichts verbaut.
Wenn vorher schon feststeht, daß viele Parameter mehrere Werte brauchen, dann ist es auch sonnvoll, erst einmal mit einer 1 als Hash-value anzufangen, um da später mal eine Referenz einzubauen. So wachsen Programme mit den Anforderungen. Hast Du einmal zu viel Flexibilität eingebaut, mußt Du sie immer mitschleppen. Fehlt sie Dir, kann man sie schnell nachrüsten, wir reden hier ja nicht über Java.
Das mit dem nicht lohnen einer Schleife hat 2 Gesichter. Klar, man muß sich erst einmal mehr Gedanken machen. Nur jedes Stück Code kann im Fehlerfall der Verursacher sein. Es ist recht einfach, später Fehler in kurzen Codestücken zu suchen. Man muß einfach weniger durchgehen. Wird der Code zu komplex, dann muß man abwägen ob man ihn schreibt oder ob man ihn incl. "fehlerunanfällige" Kommentare schreibt. Kann sein, daß es dann incl. Kommentar genau so viel Text ist, aber eben noch lange nicht so viel Code. Dann kommt noch eins dazu, komplexer Code muß nicht unperformant sein, meist ist es genau anders herum.
Ich sage das immer so:
Eine Hochsprache (Vergleich zum Maschinencode) sollte aus wenigen Hochsprachanweisungen immer viel Maschinencode erzeugen können. Dann kann dieser optimiert sein, weil man Freiheiten läßt. Schreibt man a=a+1, dann muß ein Register mit a geladen werden, und 1 dazuaddiert werden, danach muß das Ergebnis auf den Platz von a zurückgeschrieben werden. Daß a 2x vorkommt ist nicht typisch für so eine Addition, die also nicht unbedingt zu increment a optimiert werden kann. Das ist ein einfaches Beispiel. Denke da mal an %hash = map "Bild $_", (1..9, 10, 20), das könnte man auch mit for (my $i = 1; $i<=20; ++$i>=10 && $i +=10) programmieren, nur läßt man dann dem Compiler keine Wahl mehr, wie er was optimieren lassen kann. Du hast es dann exakt vorgeschrieben.\n\n
<!--EDIT|steffenw|1135113142-->
Das sorgt schon mal dafür, daß Perl dann verlangt, daß Du Deinen Code verstehst und er nicht nur einfach funktioniert. Das könnte nach der nächsten Erweiterung ja schon ganz anders aussehen. Es ist auch so, daß man den Block { no strict '???'; spezielleAnweisung; } so kurz wie möglich halten sollte. Aber wenn man genau weiß, was man tun will, ist das auch in Ordnung. Strict soll einem helfen, aber niemals ein Hindernis sein. Sonst gäbe es die no ...-Anweisungen nicht.
Schreibst Du ähnlichen Code, der sehr gleichartige Konstrukte enthält, so wie Du das gerade gemacht hast, dann schreit das regelrecht nach einer Schleife/Aliasing. Blöd war nur die sub, stimmt schon, nur weil auch da der Name auf's Auge paßte, ging das gut mit symbolischen Referenzen. Man hätte auch einen helfenden Hash einsetzen können, um "no strict" zu verhindern, siehe:
Code: (dl
)
1
2
3
4
5
6
7
8
my %hilfshash = (
name1 => sub{gleich_hingeschmierter_code},
name2 => \eine_vorhandene_sub,
);
for (qw/name1 name2/) {
print "Der Name ist $_ und die Sub macht das: ", $hilfshash{$_}->('parameter_an_die_sub');
}
Arbeite erst dann mit Referenzen, wenn sie nötig sind, nicht gleich mal so. Verkompliziere Dein Programm nicht unnötig.
Ja die Listenübergabe mit den Namen schränkt natürlich ein. Aber sie verhindert nichts, denn Du kannst sie aufbohren. Wenn ein Scalar nicht reicht, baue da später an die Stelle eine Array- oder Hash-Referenz ein und schon kannst Du mehr als einen Wert einbauen, "ref $????" hilft dann bei der Erkennung, was da angeflattert kommt. Also ist so schon mal nichts verbaut.
Wenn vorher schon feststeht, daß viele Parameter mehrere Werte brauchen, dann ist es auch sonnvoll, erst einmal mit einer 1 als Hash-value anzufangen, um da später mal eine Referenz einzubauen. So wachsen Programme mit den Anforderungen. Hast Du einmal zu viel Flexibilität eingebaut, mußt Du sie immer mitschleppen. Fehlt sie Dir, kann man sie schnell nachrüsten, wir reden hier ja nicht über Java.
Das mit dem nicht lohnen einer Schleife hat 2 Gesichter. Klar, man muß sich erst einmal mehr Gedanken machen. Nur jedes Stück Code kann im Fehlerfall der Verursacher sein. Es ist recht einfach, später Fehler in kurzen Codestücken zu suchen. Man muß einfach weniger durchgehen. Wird der Code zu komplex, dann muß man abwägen ob man ihn schreibt oder ob man ihn incl. "fehlerunanfällige" Kommentare schreibt. Kann sein, daß es dann incl. Kommentar genau so viel Text ist, aber eben noch lange nicht so viel Code. Dann kommt noch eins dazu, komplexer Code muß nicht unperformant sein, meist ist es genau anders herum.
Ich sage das immer so:
Eine Hochsprache (Vergleich zum Maschinencode) sollte aus wenigen Hochsprachanweisungen immer viel Maschinencode erzeugen können. Dann kann dieser optimiert sein, weil man Freiheiten läßt. Schreibt man a=a+1, dann muß ein Register mit a geladen werden, und 1 dazuaddiert werden, danach muß das Ergebnis auf den Platz von a zurückgeschrieben werden. Daß a 2x vorkommt ist nicht typisch für so eine Addition, die also nicht unbedingt zu increment a optimiert werden kann. Das ist ein einfaches Beispiel. Denke da mal an %hash = map "Bild $_", (1..9, 10, 20), das könnte man auch mit for (my $i = 1; $i<=20; ++$i>=10 && $i +=10) programmieren, nur läßt man dann dem Compiler keine Wahl mehr, wie er was optimieren lassen kann. Du hast es dann exakt vorgeschrieben.\n\n
<!--EDIT|steffenw|1135113142-->
$SIG{USER} = sub {love 'Perl' or die};