La chose la plus importante est de toujours lancer vos programmes avec le paramètre -w. Si vous en avez vraiment besoin, vous avez la possibilité de l'enlever explicitement pour des portions de vos programmes à l'aide du pragma "use warnings" ou de la variable $^W. Vous devriez aussi toujours utiliser "use strict" ou au moins savoir pourquoi vous ne le faites pas. Les pragmas "use sigtrap" et même "use diagnostics" pourront s'avérer utiles.
Pour ce qui est de l'esthétique du code, la seule chose à laquelle Larry tienne vraiment, c'est que les accolades fermantes d'un BLOC multiligne soient alignées avec le mot-clé qui marque le début du bloc. Après ça, il a d'autres conseils qui ne sont pas aussi forts :
Larry a ses propres raisons pour chacune de ces choses, mais il sait bien que tout le monde ne pense pas comme lui.
Voici quelques autres choses plus concrètes auxquelles il faut penser :
open(FOO,$foo) || die "J'arrive pas à ouvrir $foo: $!";
est mieux que :
die "J'arrive pas a ouvrir $foo: $!" unless open(FOO,$foo);
et ce, parce que la deuxième méthode ne met pas en avant l'instruction intéressante. D'un autre côté :
print "Début de l'analyse\n" if $verbose;
est mieux que :
$verbose && print "Début de l'analyse\n";
car l'intérêt n'est pas de savoir si l'utilisateur a tapé -v ou non.
D'une manière similaire, ce n'est pas parce qu'un opérateur suppose des arguments par défaut qu'il faut que vous utilisiez ces arguments. Les réglages par défaut sont faits pour les programmeurs systèmes paresseux qui écrivent un programme pour une seule utilisation. Si vous voulez que votre programme soit lisible, mettez les arguments.
Dans le même ordre d'idée, ce n'est pas parce que les parenthèses peuvent être omises qu'il ne faut pas en mettre :
return print reverse sort num values %array;
return print(reverse(sort num (values(%array))));
Quand vous avez un doute, mettez des parenthèses. Au moins, ça permettra aux pauvres gars de s'en remettre à la touche % sous vi.
Même si vous êtes sûr de vous, pensez à la santé mentale de la personne qui aura à mettre à jour le code après vous et qui mettra très certainement les parenthèses au mauvais endroit.
LINE:
for (;;) {
instructions;
last LINE if $truc;
next LINE if /^#/;
instructions;
}
Les noms de paquetages font parfois exception à la règle. Perl réserve de façon informelle des noms de modules en minuscules pour des modules « pragma » tels "integer" ou "strict". Les autres modules devraient commencer avec une majuscule et utiliser une casse variée, mais ne mettez pas d'underscores à cause des limitations dans les noms des modules sur certains systèmes de fichiers primitifs qui ne permettent que quelques caractères.
$TOUT_EN_MAJUSCULES les constantes uniquement (attention
aux collisions avec les variables internes
de Perl !)
$Quelques_majuscules variables globales/statiques
$pas_de_majuscule internes à une fonction (my () ou local())
Les noms de fonctions et de méthodes semblent mieux marcher quand elles sont en minuscule. Ex : $obj->as_string().
Vous pouvez utiliser un underscore au début de la variable pour indiquer qu'elle ne doit pas être utilisée hors du paquetage qui la définit.
$IDX = $ST_MTIME;
$IDX = $ST_ATIME if $opt_u;
$IDX = $ST_CTIME if $opt_c;
$IDX = $ST_SIZE if $opt_s;
mkdir $tmpdir, 0700 or die "je peux pas faire mkdir $tmpdir: $!";
chdir($tmpdir) or die "je peux pas faire chdir $tmpdir: $!";
mkdir 'tmp', 0777 or die "je peux pas faire mkdir $tmpdir/tmp: $!";
opendir(D, $dir) or die "je peux pas faire opendir $dir: $!";
tr [abc]
[xyz];
Mise à jour v5.6.0 : Paul Gaborit <Paul.Gaborit@enstimac.fr>