Débutants ou expérimentés : Comment écrire du bon code en Perl
Version courte :
- Mettez
Code:
1
2
3
| #!/usr/bin/env perl
use strict;
use warnings; |
au début de tous vos scripts.
- Indentez proprement, ou demandez à perltidy de le faire pour vous.
Code:
perltidy -b mon_script.pl
- Eventuellement demandez à perlcritic de commentez votre code, vous n'êtes pas obligé de corriger tout ce qu'il vous dit, mais ce sera déjà un bon point de départ.
- Utilisez les modules du CPAN ! Ce conseil vaut doublement pour les modules du CORE (qui viennent en standard avec Perl) excepté Switch.
- N'utilisez pas les modules pour ce que vous pouvez faire en 2 lignes !
- Utilisez les hashs, pas les tableaux, lorsque les données ont un index textuel évident pour votre utilisation des dites données dans votre script.
Bien sûr les conseils habituels à la programmation en n'importe quel langage s'appliquent :
- Donnez des noms significatifs à vos variables ! Ne basez pas vos noms sur le type du contenu, mais sur son utilisation, sa provenance et sa destination.
- Adoptez des conventions pour nommer vos variables et fonctions : en Perl la convention la plus répandu est d'utiliser des underscores "_" entre les mots, et de commencer les noms de fonctions par un verbe, mais l'important est que vous (et votre équipe) adoptiez une convention et vous y teniez, pas laquelle vous adoptez.
- Découpez votre code en fonctions : DRY, Don't Repeat Yourself (Ne vous répétez pas !).
- Découpez votre application en modules.
- N'utilisez pas goto (sauf la version "goto fonction" spécifique au Perl, si vous savez ce que vous faites).
- N'utilisez les variables globales que contraints et forcés ou pour des variables de configuration. Déclarez vos variables avec my() !
Version longue (aka "Les explications") :
La devise de Perl est TIMTOWDI, c'est-à-dire "There Is More Than One Way To Do It", en français : "Il y a plus d'une façon de le faire !".
Et effectivement Perl est un langage très flexible et puissant dans lequel vous pouvez adopter une multitude de méthodes différentes pour parvenir au même résultat.
Malheureusement, cela ne signifie pas que toutes les méthodes sont également viables, également efficaces, ou également faciles à entretenir ou lisibles...
Dans ce topic, je vais donc indiquer quelques points qui me semblent importants pour obtenir un résultat potable. Ce sujet est destiné aussi bien aux novices qu'aux expérimentés (je ne dirais pas aux experts, il n'y a pas beaucoup d'"experts" en Perl, et à mon avis ceux qui le sont doivent déjà savoir tout ce que je vais dire).
Le pragma "strict"
Qu'est-ce qu'un pragma ? C'est une instruction au compilateur/interpréteur qui modifie le comportement du langage sur une portée limitée. En Perl les pragmas sont chargés avec "use" ou déchargés avec "no", leur nom est tout en minuscule, contrairement aux noms de modules qui par convention doivent commencer par une majuscule.
Le pragma "strict" interdit l'usage d'un certains nombre de constructions normalement valables en Perl mais qui sont responsables de la plupart des erreurs basiques que peuvent rencontrer un novice, voire parfois un expert.
Pourquoi ces constructions ne sont-elles pas simplement supprimés du langage si elles sont si dangereuse me demanderez vous. Pour trois raisons :
- Le poids de l'histoire : Perl est un "vieux" langage, qui a commencé ses jours comme une simple glue Unix, alors que les shells étaient encore plus rudimentaires qu'aujourd'hui, il a retenu certains des défauts des shells de l'époque, défauts peu important pour un petit script de quelques lignes, beaucoup plus pour un programme constitué d'une vingtaines de modules... Mais l'une des fiertés de Perl est sa compatibilité en arrière dans le temps (backward compatibility), autrement dit sa capacité à faire tourner des scripts vieux de 10 ans sans modifications. Ce trait est assez rare pour le type de langage que Perl représente et il y réussit effectivement de façon impressionnante.
- L'utilité de ces constructions : en effet certaines de ces constructions peuvent se révéler utiles dans des cas très particuliers et pour faire des choses relevant de la magie noire. Mais ceci ne vous concerne que si vous avez l'habitude de mettre des modules complexes sur le CPAN, qui touchent au comportement même de Perl ou ce genre de chose.
- Dans un très petit script (ne dépassant pas dix lignes à mon avis, mais d'autres seront plus larges dans leur appréciation) ou un uniligne utiliser ces constructions interdites ne prête pas vraiment à conséquences et se les interdire alourdirait inutilement le programme.
Mais quels sont donc les effets concrets de strict ? Sans rentrer dans le détail, les principaux effets sont l'obligation de déclarer toutes ses nouvelles variables (avec my() pour les variables lexicales, our() pour les variables globales de paquetage), l'interdiction des mots "nus" (barewords, autrement dit, sans 'strict' Perl interprète tout mot isolé qu'il ne reconnait pas (pas un nom de fonction ou de HANDLE de fichier) comme une chaîne de caractères), et l'interdiction des références symboliques (l'utilisation d'une chaîne de caractère variable comme nom de variable).
Le pragma "warnings"
A partir de Perl 5.6 vous pouvez utiliser ce pragma en remplacement de l'option en ligne de commande -w (qu'on pouvait également indiquer sur la ligne de shebang d'un script). Il active les avertissements de Perl, qui vous indiquent les constructions douteuses ou ressemblant à des erreurs classiques dans votre code, à l'exécution comme à la compilation. Il ne s'agira pas toujours d'erreurs réelles, mais souvent un meilleur style de programmation peut faire disparaître ces avertissements, et dans les rares cas ou vous vous estimez justifié dans votre utilisation, un autre avantage du pragma warnings apparaîtra : vous pouvez le désactivez sélectivement sur une portion de code donnée et pour certains types d'avertissements précisément, lisez "perldoc perllexwarn" pour une explication en profondeur des avantages du pragma sur l'option -w.
Perl::Tidy
Le module Perl::Tidy et l'utilitaire perltidy qui vient avec ce module permettent de reformater aisément son code Perl, par exemple pour le mettre en conformité avec une norme d'entreprise ou un format que vous préférez à celui employé dans le code d'origine. Le formatage est complètement configurable et vous pouvez ainsi façonner le résultat exactement à votre goût. Indispensable !!
Perl::Critic
Perl::Critic et l'utilitaire perlcritic associé critique votre code selon un certain nombre de règles de bonne pratique décrites sous forme de module, dont beaucoup sont distribuées avec Perl::Critic (mais pas toutes), vous pouvez configurer exactement lesquelles prendre en compte (en plus du système de "niveau de sévérité" intégré à Perl::Critic) ou même en écrire de nouvelle.
En complément de cela si vous avez le temps (ou les sous), lisez "Perl Best Practices" ou sa traduction française "De l'art de programmer en Perl", excellent bouquin, qui se lit facilement, ( mais un peu cher :aie: ) et qui a servi de base à perlcritic.
Les modules et le CPAN
Ne réinventez pas la roue : surtout si vous êtes débutant (et que vous n'êtes pas en train de coder dans un but pédagogique), le code que vous produirez sera sans doute moins bon, moins robuste, moins efficace que le module du CPAN correspondant, et en plus il sera plus long à réécrire. Pensez toujours au CPAN, faites vos recherches dessus avec le site officiel ou le CPAN pour Win32 (qui vous indiquera où trouver vos paquetages ppm).
Ce qui ne veut pas dire que votre programme doit ressembler à une collection de modules du CPAN ! N'utilisez pas un module pour une seule fonction facilement refaites en quelques lignes par vous même (n'oubliez pas néanmoins que parfois la fonction du module a été écrite pour effectuer cette tâche bien plus rapidement et de façon bien plus robuste que votre pauvre petit remplacement). Ceci ne vaut pas pour les modules du CORE, ils sont disponibles partout (ou presque, utilisez Module::CoreList pour en avoir le coeur net) et sont la plupart du temps très bien codés donc n'hésitez surtout pas à les utiliser (sauf Switch, oubliez cette abomination !! Si vous voulez un switch..case en Perl, utilisez Perl5.10 qui devrait sortir cette année (2007) et offrir un très bon switch intégré. Les hashs sont souvent également une excellente alternative à la plupart des usages de switch..case).
Il y a également le cas où vous n'êtes pas tout à fait satisfait des modules disponibles sur le CPAN, n'hésitez pas alors à vous lancer dans la création d'un nouveau module (si vous êtes un programmeur suffisamment expérimenté), c'est ainsi qu'on fait progresser les choses ! Vous pouvez également proposer un patch à l'auteur d'un des modules du CPAN : s'il améliore les choses, ne brise pas la compatibilité arrière et relève vraiment du module, il sera très certainement accepté.
--
Jedaï
"Découpez votre code en fonctions" oui mais...
Bonjour,
En lisant votre article, il me vient une foule de questions que je résumerais en une grande question "bateau"... Qu'en est-il du temps d'exécution? Oui, il faut découper son script en sous-programmes, en modules, etc. Mais jusqu'à quel point? Je me souviens d'un script php que j'avais encodé comme un cochon, répetant les mêmes lignes de codes des dizaines et dizaines de fois . Lorsque j'ai entrepris de nettoyer ce script, certes j'ai réduis mon code de plus de 800 lignes en moins de 120 mais le temps d'exécution avait plus que doublé. Qu'en est-il avec Perl?
