folgend ein paar anmerkungen zum stil, nichts davon ist zwingend. es ist lediglich der stil, den ich am häufigsten beobachte:

wenn man seinen code verbreiten will, macht es imho sinn, die zeilen auf 80 zeichen breite zu beschränken, da das die standartbreite bei terminals ist und von vielen geren verwendet wird.

der schliessenden geschweiften klammer, die einen block abschliesst, würde ich eine eigene zeile spendieren, die so weit eingerückt ist, wie die zeile in der der block geöffnet wird.

die sub countown ist irgendwie eigentümlich eingerückt. ist das die schuld des forums?

was mich noch auf einen weiteren tip bringt. niemals tabulatoren und leerzeichen beim einrücken mischen. du kannst nie wissen, wie weit tabulatoren bei anderen viewern eingerückt werden.

[quote=Taulmarill,10.08.2005, 12:54]was mich noch auf einen weiteren tip bringt. niemals tabulatoren und leerzeichen beim einrücken mischen. du kannst nie wissen, wie weit tabulatoren bei anderen viewern eingerückt werden.[/quote]
Tab = 8 Zeichen. Wenn Editoren oder Viewer das anders machen (by default), dann sind sie buggy.

[quote=ptk,10.08.2005, 13:12]Tab = 8 Zeichen. Wenn Editoren oder Viewer das anders machen (by default), dann sind sie buggy.[/quote]
achso, und jeder, der tabulatoren auf != 8 zeichen einstellt ist ein ketzer und gehört auf den scheiterhaufen? du bist ja lustig.
ich habe ja im prinzip nichts gegen tabs, aber man sollte sie nicht mit leerzeichen mischen, das fürt bei den meisten zu problemen in der anzeige.

x) use strict und use warnings sollten eigentlich bei jedem programm pflicht sein; -w war frueher mal gut, aber heutzutage sollte man besser warnings verwenden, weil -w immer global ist (d.h. auch fuer module wirkt, die man selbst gar nicht geschrieben hat), waehrend warnings nur immer im lokalen kontext (z.b. der aktuellen datei) gueltig ist.

x) nochmal zurueck zur datei ".termine": (btw: in strings hat der punkt keine sonderbedeutung; dort brauchst du ihn also nicht zu escapen)

du verwendest sie in fast jeder sub; will die nicht in eine eigene Variable? Wenn sich der Namen der Datei aendern sollte, wie viele vorkommen musst du denn jetzt aendern?

x) Die Datei liegt immer im aktuellen verzeichnis; was passiert, wenn das script von einem anderen verzeichnis ausgefuehrt wird? (z.B. ../my/script.pl) wohin wird die dann geschrieben? entweder einen fixen pfad vorgeben (z.B. das empfohlene HOME), oder den relativ-absolut zum scriptverzeichnis machen.


x) Uebergibst Du nicht gerne Variablen an subroutinen? Bei countdown (my $line=$_;) greifst du einfach auf das globale $_ zu, und hast somit eine verdeckte parameteruebergabe, die unnoetige komplexitaet reinbringt. Am besten finde ich, wenn Subroutinen nur ueber eine klare Schnittstelle mit aussen kommunizieren, und diese schnittstellen sind ein- und ausgabeparameter...

x) du oeffnest die datei recht haeufig zum lesen (warum machst du da eigentlich nie eine fehlerabfrage? was passiert, wenn die datei mal nicht vorhanden ist, weil sie im falschen verzeichnis gesucht wird?) und machst danach mehr oder weniger immer dasselbe. koennte man das parsen der datei nicht in eine gemeinsame subroutine auslagern, sodass der code schlanker und klarer wird?

[quote=Strat,10.08.2005, 14:06][quote=ptk,10.08.2005, 13:57]Wenn derjenige seinen Code nicht veroeffentlicht, dann ist es mir egal. Wenn er
in seine Datei schreibt, dann kann ich wenigstens die Datei im Emacs richtig lesen, aber man muesste das gleiche fuer den vi und alle anderen Editoren machen.

Sich vorzunehmen, Leerzeichen und Tabs nicht zu mischen, ist schoen gedacht, aber was ist, wenn die Datei von jemand anders editiert wird, der diese (private!) Konvention nicht kennt?[/quote]
da faende ich es genial, wenn der editor beim speichern alle fuehrenden tabs durch leerzeichen ersetzen wuerde, und zwar durch so viele, wie man eingestellt hat (oder alternativ: nur tabs zum einruecken verwenden, dann ist es egal)[/quote]
Lieber nicht. Es koennten falsche Tabs ersetzt werden, z.B. wenn man ein literales Tab statt eines \t in einem String hat. Ausserdem mag ich es nicht, wenn ein Editor selbstaendig Whitespace aendert. Erst gestern habe ich auf unseren Trainee geschimpft, weil sein Editor die Unix-Newlines in Dos-Newlines geaendert hat und die Dateien ins CVS eingecheckt hat. Ein "cvs diff" wird dann nutzlos (OK, es gibt zur Not die Optionen -bB).

Wenn schon umwandeln, dann muesste der Editor schon beim Betaetigen des TAB nur Spaces einfuegen.

Dort steht nur: "4 column indent". Dort steht nicht, dass man Spaces dafuer verwenden muss. Mein Emacs, macht bei einem Tab eine korrekte Einrueckung in 4er-Schritten und erzeugt dabei Spaces und/oder Tabulatoren, je nachdem, was weniger Platz einnimmt.\n\n

<!--EDIT|ptk|1123680295-->

Mit 8 Spalten meine ich die Auswirkung eines physikalischen Tab (aka "\t"), das sich in einer Datei befindet. Was bei einem Druck auf die Tab-Taste passiert, ist eine andere Geschichte. Wie gesagt, ich bevorzuge ebenfalls eine Einruecktiefe von 4.