Die folgenden Regeln haben das Ziel, den Code möglichst gut les- +
Die folgenden Regeln haben das Ziel, den Code möglichst gut les- und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden wird (Stichworte "Klammern" oder "Hash-Keys").
Diese Regeln sind keine Schikane sondern erleichtern allen das @@ -66,7 +66,7 @@ map { $form->{sum} += $form->{"row_$_"} } 1..$rowcount;
Seitliche hängende Kommentare sollten einheitlich formatiert werden.
Sämtliche Kommentare und Sonstiges im Quellcode ist bitte auf Englisch zu verfassen. So wie ich keine Lust habe, - französischen Quelltext zu lesen, sollte auch der Lx-Office + französischen Quelltext zu lesen, sollte auch der kivitendo Quelltext für nicht-Deutschsprachige lesbar sein. Beispiel:
my $found = 0;
while (1) {
@@ -105,7 +105,7 @@ $some_hash{42} = 54;Die maximale Zeilenlä -aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79 -lp -vt=1 -vtc=1
STDERR ist tabu. Unkonditionale
- Debugmeldungen auch.
Lx-Office bietet mit dem Modul LXDebug
+ Debugmeldungen auch.
kivitendo bietet mit dem Modul LXDebug
einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen
Grund, nach STDERR zu schreiben.
Die LXDebug-Methode
"message" nimmt als ersten Paramter auÃerdem