perlstyle - En ligne dans le Cloud

PROGRAMME:

Nom

perlstyle - Guide de style Perl

DESCRIPTION

Chaque programmeur aura bien entendu ses propres préférences en matière de formatage,
mais il existe quelques directives générales qui rendront vos programmes plus faciles à lire,
comprendre et maintenir.

La chose la plus importante est d'exécuter vos programmes sous le -w drapeau à tout moment. Tu peux
désactivez-le explicitement pour des portions de code particulières via le pragma "pas d'avertissement" ou le
$^W variable si vous devez. Vous devez également toujours exécuter sous « use strict » ou connaître le
raison pourquoi pas. Les pragmas « use sigtrap » et même « use diagnostics » peuvent également s'avérer
utile.

En ce qui concerne l'esthétique du code, la seule chose à laquelle Larry se soucie fortement est
que l'accolade fermante d'un BLOC de plusieurs lignes doit s'aligner avec le mot-clé qui
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 alignez-vous.

· Espace avant l'ouverture bouclée d'un BLOC multiligne.

· Un BLOC d'une ligne peut être placé sur une seule ligne, y compris les boucles.

· Pas d'espace avant le point-virgule.

· Point-virgule omis dans le BLOC "court" d'une ligne.

· Espace autour de la plupart des opérateurs.

· Espace autour d'un indice "complexe" (entre crochets).

· Des lignes vides entre les morceaux qui font des choses différentes.

· Les autres non câlinés.

· Pas d'espace entre le nom de la fonction et sa parenthèse ouvrante.

· Espace après chaque virgule.

· Lignes longues interrompues après un opérateur (sauf "et" et "ou").

· Espace après la dernière parenthèse correspondant à la ligne actuelle.

· Alignez les éléments correspondants verticalement.

· Omettez la ponctuation redondante tant que la clarté n'en souffre pas.

Larry a ses raisons pour chacune de ces choses, mais il ne prétend pas que tout le monde
l'esprit fonctionne de la même manière que le sien.

Voici quelques autres questions de style plus importantes auxquelles réfléchir :

· Juste parce que vous CAN faire quelque chose d'une manière particulière ne signifie pas que vous DEVRAIT faire
de cette façon. Perl est conçu pour vous donner plusieurs façons de faire quoi que ce soit, alors considérez
choisir le plus lisible. Par exemple

ouvrir(FOO,$foo) || die "Impossible d'ouvrir $foo : $ !" ;

est mieux que

die "Impossible d'ouvrir $foo: $!" sauf si ouvert(FOO,$foo);

parce que la deuxième façon cache le point principal de l'instruction dans un modificateur. Sur le
d'autre part

print "Démarrage de l'analyse\n" if $verbose ;

est mieux que

$verbose && print "Démarrage de l'analyse\n";

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

De même, juste parce qu'un opérateur vous permet de supposer des arguments par défaut ne signifie pas
que vous devez utiliser les valeurs par défaut. Les valeurs par défaut sont là pour les systèmes paresseux
programmeurs écrivant des programmes ponctuels. Si vous voulez que votre programme soit lisible,
envisager de fournir l'argument.

Dans le même sens, juste parce que vous CAN omettre les parenthèses dans de nombreux endroits ne
signifie que vous devez :

return print tri inversé num valeurs %array;
return print(reverse(sort num (values(%array))));

En cas de doute, mettez une parenthèse. À tout le moins, il laissera un pauvre schmuck rebondir
sur la touche % dans vi.

Même si vous n'avez aucun doute, pensez au bien-être mental de la personne qui doit
maintenir le code après vous, et qui mettra probablement les parenthèses au mauvais endroit.

· Ne faites pas de contorsions stupides pour sortir d'une boucle en haut ou en bas, lorsque Perl
fournit le "dernier" opérateur afin que vous puissiez sortir au milieu. Il suffit de "dépasser" un
peu pour le rendre plus visible :

LIGNE:
pour (;;) {
Déclarations;
dernière LIGNE si $foo ;
LIGNE suivante si /^#/;
Déclarations;
}

· N'ayez pas peur d'utiliser des étiquettes de boucle - elles sont là pour améliorer la lisibilité ainsi que pour
permettre des ruptures 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
eux. Sinon, utilisez plutôt une boucle "foreach()" ou la fonction "system()".

· Pour la portabilité, lors de l'utilisation de fonctionnalités qui peuvent ne pas être implémentées sur chaque machine,
testez la construction dans un eval pour voir si elle échoue. Si vous savez quelle version ou
patchlevel une fonctionnalité particulière a été implémentée, vous pouvez tester $] ($PERL_VERSION dans
"Anglais") pour voir s'il sera là. Le module "Config" vous permettra également
interroger les valeurs déterminées par le Configurez programme lorsque Perl a été installé.

· Choisissez des identifiants mnémoniques. Si vous ne vous souvenez pas de ce que signifie mnémonique, vous avez un
problème.

· Bien que les identifiants courts comme $gotit soient 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 un simple
règle qui fonctionne de manière cohérente avec "VAR_NAMES_LIKE_THIS".

Les noms de paquet sont parfois une exception à cette règle. Perl réserve officieusement
noms de module en minuscules pour les modules "pragma" comme "integer" et "strict". Autre
les modules doivent commencer par une majuscule et utiliser la casse mixte, mais probablement sans
souligne en raison des limitations dans les représentations du module par les systèmes de fichiers primitifs
noms sous forme de fichiers qui doivent tenir dans quelques octets clairsemés.

· Vous pouvez trouver utile d'utiliser la casse des lettres pour indiquer la portée ou la nature d'un
variable. Par example:

Constantes $ALL_CAPS_HERE uniquement (attention aux conflits avec les variables perl !)
$Some_Caps_Here global/statique à l'échelle du package
$no_caps_here portée de la fonction my() ou variables locales()

Les noms de fonction et de méthode semblent fonctionner mieux en minuscules. Par exemple,
"$obj->as_string()".

Vous pouvez utiliser un trait de soulignement pour indiquer qu'une variable ou une fonction ne doit pas être
utilisé en dehors du package qui l'a défini.

· Si vous avez une expression régulière vraiment velue, utilisez le modificateur "/x" et mettez quelques
un espace blanc pour que cela ressemble un peu moins à du bruit de ligne. N'utilisez pas de barre oblique comme
délimiteur lorsque votre regexp a des barres obliques ou des barres obliques inverses.

· Utilisez les nouveaux opérateurs « et » et « ou » pour éviter d'avoir à mettre les opérateurs de liste entre parenthèses afin
beaucoup, et pour réduire l'incidence des opérateurs de ponctuation comme "&&" et "||". Appel
vos sous-programmes comme s'il s'agissait de fonctions ou d'opérateurs de liste pour éviter les excès
esperluettes et parenthèses.

· Utilisez ici des documents au lieu d'instructions "print()" répétées.

· Alignez les éléments correspondants verticalement, surtout s'il serait trop long de tenir sur un
ligne quand même.

$IDX = $ST_MTIME ;
$IDX = $ST_ATIME si $opt_u ;
$IDX = $ST_CTIME si $opt_c ;
$IDX = $ST_SIZE si $opt_s ;

mkdir $tmpdir, 0700 ou die "can't mkdir $tmpdir: $!";
chdir($tmpdir) ou die "can't chdir $tmpdir: $!";
mkdir 'tmp', 0777 ou die "can't mkdir $tmpdir/tmp: $!";

· Vérifiez toujours les codes de retour des appels système. Les bons messages d'erreur devraient aller à
"STDERR", indiquez quel programme a causé le problème, quel appel système a échoué et
arguments étaient, et (TRÈS IMPORTANT) devraient contenir le message d'erreur système standard
pour ce qui s'est mal passé. Voici un exemple simple mais suffisant :

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

· Alignez vos translittérations lorsque cela a du sens :

tr [abc]
[xyz] ;

· Pensez à la réutilisation. Pourquoi gaspiller de l'intelligence sur un one-shot alors que vous voudriez peut-être le faire
quelque chose comme ça encore? Pensez à généraliser votre code. Envisagez d'écrire un module
ou classe d'objets. Pensez à faire fonctionner votre code proprement avec "use strict" et "use
avertissements" (ou -w) en effet. Pensez à donner votre code. Pensez à changer votre
vision du monde entier. Considérez... oh, peu importe.

· Essayez de documenter votre code et utilisez le formatage Pod de manière cohérente. Voici
conventions communément attendues :

· utiliser "C<>" pour les noms de fonction, de variable et de module (et plus généralement n'importe quoi
qui peuvent être considérés comme faisant partie du code, comme des descripteurs de fichiers ou des valeurs spécifiques). Noter
que les noms de fonction sont considérés comme plus lisibles avec des parenthèses après leur
nom, c'est-à-dire "fonction()".

· utilisez "B<>" pour les noms de commandes comme cat or grep.

· utilisez "F<>" ou "C<>" pour les noms de fichiers. "F<>" devrait être le seul code Pod pour le fichier
noms, mais comme la plupart des formateurs de Pod le rendent en italique, chemins Unix et Windows avec
leurs barres obliques et barres obliques inverses peuvent être moins lisibles et mieux rendues avec
"C<>".

· Être cohérent.

· Sois gentil.

Utilisez perlstyle en ligne en utilisant les services onworks.net