Perl - Norme de codage

Chaque programmeur aura, bien sûr, ses propres préférences en ce qui concerne le formatage, mais il existe quelques directives générales qui faciliteront la lecture, la compréhension et la maintenance de vos programmes.

Le plus important est d'exécuter vos programmes sous l'option -w à tout moment. Vous pouvez le désactiver explicitement pour des portions de code particulières via le pragma no warnings ou la variable $ ^ W si vous le devez. Vous devez également toujours exécuter sous use strict ou en connaître la raison. L'utilisation de sigtrap et même l'utilisation de pragmas de diagnostic peuvent également s'avérer utiles.

En ce qui concerne l'esthétique de la disposition du code, la seule chose à laquelle Larry se soucie fortement est que l'accolade fermante d'un BLOC multiligne doit s'aligner avec le mot-clé qui a commencé la construction. Au-delà de cela, il a d'autres préférences qui ne sont pas si fortes -

Retrait de 4 colonnes.
Ouverture bouclée sur la même ligne que le mot-clé, si possible, sinon aligner.
Espace avant l'ouverture bouclée d'un BLOC multiligne.
Le BLOC d'une ligne peut être placé sur une ligne, y compris les boucles.
Pas d'espace avant le point-virgule.
Point-virgule omis dans BLOC "court" d'une ligne.
Espace autour de la plupart des opérateurs.
Espace autour d'un indice "complexe" (entre crochets).
Lignes vides entre les morceaux qui font des choses différentes.
Elles sans câlins.
Aucun espace entre le nom de la fonction et sa parenthèse ouvrante.
Espace après chaque virgule.
Longues lignes interrompues après un opérateur (sauf et et ou).
Espace après la dernière parenthèse correspondant à la ligne courante.
Alignez les éléments correspondants verticalement.
Omettez la ponctuation redondante tant que la clarté ne souffre pas.

Voici quelques autres problèmes de style plus substantiels auxquels il faut réfléchir: Ce n'est pas parce que vous POUVEZ faire quelque chose d'une manière particulière que vous DEVRIEZ le faire de cette façon. Perl est conçu pour vous donner plusieurs façons de faire n'importe quoi, alors pensez à choisir la plus lisible. Par exemple -

open(FOO,$foo) || die "Can't open $foo: $!";

Vaut mieux que -

die "Can't open $foo: $!" unless open(FOO,$foo);

Parce que la deuxième manière masque le point principal de l'instruction dans un modificateur. D'autre part,

print "Starting analysis\n" if $verbose;

Vaut mieux que -

$verbose && print "Starting analysis\n";

Parce que le point principal n'est pas de savoir si l'utilisateur a tapé -v ou non.

Ne passez pas par des contorsions idiotes pour sortir d'une boucle en haut ou en bas, lorsque Perl fournit le dernier opérateur pour que vous puissiez sortir au milieu. Juste "surpasser" un peu pour le rendre plus visible -

LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}

Voyons quelques points plus importants -

N'ayez pas peur d'utiliser des étiquettes de boucle - elles sont là pour améliorer la lisibilité et pour permettre des sauts de boucle à plusieurs niveaux. Voir l'exemple précédent.
Évitez d'utiliser grep () (ou map ()) ou `backticks` dans un contexte vide, c'est-à-dire lorsque vous jetez simplement leurs valeurs de retour. Ces fonctions ont toutes des valeurs de retour, alors utilisez-les. Sinon, utilisez plutôt une boucle foreach () ou la fonction system ().
Pour la portabilité, lorsque vous utilisez des fonctionnalités qui peuvent ne pas être implémentées sur chaque machine, testez la construction dans une évaluation pour voir si elle échoue. Si vous connaissez la version ou le niveau de patch d'une fonctionnalité particulière, vous pouvez tester $] ($ PERL_VERSION en anglais) pour voir si elle sera là. Le module Config vous permettra également d'interroger les valeurs déterminées par le programme Configure lors de l'installation de Perl.
Choisissez des identifiants mnémotechniques. Si vous ne vous souvenez pas de ce que signifie mnémotechnique, vous avez un problème.
Alors que les identifiants courts comme $ gotit sont probablement corrects, utilisez des traits de soulignement pour séparer les mots dans des identifiants plus longs. Il est généralement plus facile de lire $ var_names_like_this que $ VarNamesLikeThis, en particulier pour les locuteurs non natifs de l'anglais. C'est aussi une règle simple qui fonctionne de manière cohérente avec VAR_NAMES_LIKE_THIS.
Les noms de packages sont parfois une exception à cette règle. Perl réserve de manière informelle des noms de modules en minuscules pour les modules "pragma" comme integer et strict. Les autres modules doivent commencer par une majuscule et utiliser une casse mixte, mais probablement sans traits de soulignement en raison des limitations dans les représentations des noms de modules par les systèmes de fichiers primitifs en tant que fichiers qui doivent tenir dans quelques octets épars.
Si vous avez une expression régulière vraiment velue, utilisez le modificateur / x et mettez un espace pour la faire ressembler un peu moins au bruit de ligne. N'utilisez pas de barre oblique comme délimiteur lorsque votre expression rationnelle a des barres obliques ou des barres obliques inverses.
Vérifiez toujours les codes de retour des appels système. Les bons messages d'erreur doivent être envoyés à STDERR, inclure le programme à l'origine du problème, l'appel système ayant échoué et les arguments, et (TRÈS IMPORTANT) doit contenir le message d'erreur système standard pour ce qui s'est mal passé. Voici un exemple simple mais suffisant -

opendir(D, $dir) or die "can't opendir $dir: $!";

Pensez à la réutilisabilité. Pourquoi gaspiller votre cerveau en un seul coup alors que vous voudrez peut-être refaire quelque chose comme ça? Pensez à généraliser votre code. Envisagez d'écrire un module ou une classe d'objets. Envisagez de faire en sorte que votre code s'exécute proprement avec use strict et utilisez les avertissements (ou -w) en vigueur. Pensez à donner votre code. Pensez à changer votre vision du monde. Considérez ... oh, peu importe.
Être cohérent.
Sois gentil.