Les Mongueurs de Perl / Groupe de travail Articles / Conférences Perl

Nous rejoindre / SVN / Relecture / Rédaction / Planning / Liens /

Publications : Linux Magazine France, Perles, Brèves, Production, Comptes-Rendus, Interviews, Traductions, Spoofathon

• Ce n'est pas personnel

  Oubliez la propriété du code. Vous vous prenez peut-être pour un artiste, mais même les Grands Maîtres ont fait beaucoup de merdes. Le code de tout un chacun est de la merde, ce qui veut dire que mon code c'est de la merde et le vôtre aussi. Apprenez à apprécier cela. Quand vous avez un problème, votre première pensée devrait être « Il y a quelque chose qui foire avec mon code de merde ». Ça veut dire que vous n'avez pas à blâmer Perl. Ce n'est pas personnel.

  Oubliez comment vous faites les choses. Si la façon dont vous faites les choses marchait, vous ne liriez pas ces lignes. Ce n'est pas grave. Il est temps d'évoluer, nous sommes tous passés par là.

• La responsabilité personnelle

  Si vous avez un problème avec votre script, c'est votre problème ; à vous. Vous devriez faire tout votre possible pour le résoudre par vous-même. Souvenez-vous que tout le monde a ses propres scripts, ce qui signifie que tout le monde a ses propres problèmes. Faites vos devoirs de votre mieux, avant d'allez ennuyer quelqu'un avec vos problèmes. Si vous essayez sérieusement tout ce qu'il y a dans ce guide et que vous n'arrivez toujours pas à résoudre votre problème, alors vous avez fait de votre mieux et il est temps d'ennuyer quelqu'un d'autre.

• Changez votre façon de faire

  Changez les choses de façon à ne plus avoir à nouveau le même problème. Le problème vient probablement de comment vous codez et non de ce que vous codez. Changez votre façon de faire pour vous faciliter la vie. Ne demandez pas à Perl de s'adapter à vous, car il ne le fera pas. Adaptez-vous à Perl. C'est un langage de programmation, pas une façon de vivre.

• Est-ce que votre script compile avec les strictures ?

  Si vous n'utilisez pas déjà les strictures, faites-le. Les gourous de Perl sont des gourous parce qu'utiliser strict leur laisse plus de temps pour résoudre d'autres problèmes, apprendre de nouvelles choses et ajouter des modules qui fonctionnent sur CPAN.

  Vous pouvez déclencher les strictures depuis le code avec la pragma strict.

      use strict;

  Vous pouvez déclencher les strictures depuis la ligne de commande avec l'option -M de perl.

      perl -Mstrict script.pl

  Peut-être les strictures vous ennuyeront-elles, mais au bout de quelques semaines de programmation avec, vous écrirez un code meilleur, vous passerez moins de temps à courir après des erreurs simples et vous n'aurez probablement plus besoin de ce guide.

• Quel est l'avertissement ?

  Perl va vous avertir au sujet de nombreuses constructions douteuses. Enclenchez les avertissements et laissez Perl vous aider.

  Vous pouvez utiliser l'option -w de perl sur la ligne shebang.

      #!/usr/bin/perl -w

  Vous pouvez déclencher les avertissements depuis la ligne de commande.

      perl -w script.pl

  Vous pouvez utilisez les avertissement lexicaux qui ont toutes sortes de fonctionnalités intéressantes. Voir warnings(3pm) pour les détails.

      use warnings;

  Si vous ne comprenez pas un avertissement, vous pouvez consulter une explication plus complète de l'avertissement dans perldiag(1) ou vous pouvez utiliser la pragma diagnostics dans votre code.

      use diagnostics;

• Résolvez le premier problème d'abord !

  Après avoir eu des messages d'erreur ou d'avertissement de la part de perl, corrigez le premier message, puis vérifiez si perl continue d'afficher les autres messages. Ces messages supplémentaires peuvent être des conséquences du premier problème.

• Regardez le code qui précède la ligne citée dans le message d'erreur !

  Perl vous renvoie des messages d'erreur quand il commence à s'inquiéter, mais pas avant. Au moment où perl s'inquiète, le problème s'est déjà produit et la ligne où se trouve perl est en réalité après le problème. Regardez les quelques expressions qui précèdent la ligne citée dans l'avertissement.

• La valeur est-elle celle que vous croyez ?

  Ne jouez pas aux devinettes ! Examinez vraiment la valeur juste avant de l'utiliser dans une expression. Le meilleur débogueur de l'univers, c'est print.

      print STDERR "La valeur est [$valeur]\n";

  J'entoure $valeur de crochets afin de voir tout blanc ou saut de ligne au début ou à la fin de la chaîne.

  Si j'ai autre chose qu'un scalaire, j'utilise Data::Dumper pour afficher les structures de données.

      require Data::Dumper;
  
      print STDERR "Le hachage est ", Data::Dumper::Dumper( \%hash ), "\n";

  Si la valeur n'est pas celle que vous croyez, reculez de quelques étapes, et essayez à nouveau. Recommencez jusqu'à que ce vous ayez trouvé le moment où la valeur cesse de valoir ce que vous pensez qu'elle doit valoir !

  Vous pouvez aussi utiliser le débogueur intégré de perl avec l'option -d de perl. Consultez perldebug(1) pour les détails.

      perl -d script.pl

  Vous pouvez aussi utiliser d'autres débogueurs ou environnements de développement, comme ptkdb (un débogueur graphique en Tk) ou Komodo (l'IDE Perl d'ActiveState basé sur Mozilla).

• Utilisez-vous la fonction correctement ?

  Cela fait un moment que je programme en Perl et je continue de regarder perlfunc(1) presque tous les jours. Il y a des choses que je n'arrive pas à retenir correctement et j'ai parfois veillé tellement longtemps que je perds complètement la tête et je me demande pourquoi sprintf() n'affiche rien à l'écran.

  Vous pouvez rechercher une fonction en particulier avec la commande perldoc et son option -f.

      perldoc -f fonction

  Si vous utilisez un module, utilisez la documentation pour vous assurer que vous l'utilisez comme il faut. Vous pouvez consulter la documentation d'un module avec perldoc.

      perldoc Mon::Module

• Utilisez-vous la bonne variable spéciale ?

  Là encore, je me réfère constamment à perlvar(1). En fait, pas vraiment, car je trouve Perl précis et concis plus facile à utiliser.

• Avez-vous la bonne version du module ?

  Le fonctionnement de certains modules change entre les versions. Avez-vous la version du module que vous croyez avoir ? Vous pouvez vérifier la version de la plupart des modules avec un simple uniligne perl.

      perl -MMon::Module -le 'print Mon::Module->VERSION';

  Si vous consultez l'essentiel de votre documentation sur des sites externes, comme http://www.perldoc.com/ ou http://search.cpan.org/, alors vous avez encore plus de chances de rencontrer des différences de version dans la documentation.

• Avez-vous fait un petit cas de test ?

  Si vous essayez un truc nouveau, ou si vous pensez qu'un bout de code en particulier fonctionne bizarrement, écrivez le programme le plus court possible pour ne faire que cela. Cela supprime la plupart des autres facteurs à prendre en compte. Si le petit programme de test fait ce que vous pensez qu'il doit faire, alors le problème n'est probablement pas dans ce code. Si le programme ne fait pas ce que vous pensez qu'il doit faire, alors vous venez peut-être de trouver votre problème.

• Avez-vous vérifié l'environnement ?

  Certaines choses dépendent des variables d'environnement. Êtes-vous sûr qu'elles sont mises à la bonne valeur ? Est-ce que votre environnement est le même que celui que le programme verra quand vous l'exécuterez ? Souvenez-vous que les programmes destinés à être des CGI ou des tâches pour cron peuvent voir des environnements différents de celui de votre terminal interactif, en particulier sur des machines différentes.

  Perl stocke son environnement dans %ENV. Si vous avez besoin de l'une de ces variables, soyez prêts à fournir une valeur par défaut si elle n'existe pas, même à des fins de test.

  Et si vous avez encore des soucis, inspectez l'environnement.

      require Data::Dumper;
      print STDERR Data::Dumper::Dumper( \%ENV );

• Avez-vous consulté Google ?

  Si vous avez un problème, quelqu'un d'autre l'a probablement déjà eu. Vérifiez si quelqu'un d'autre n'a pas déjà écrit quelque chose sur les groupes de news comp.lang.perl.misc ou fr.comp.lang.perl en cherchant dans les groupes Google (http://groups.google.com/). La différence entre les personnes qui posent les questions sur usenet et ceux qui y répondent est leur capacité à utiliser les groupes Google efficacement.

• Avez-vous profilé l'application ?

  Si vous voulez trouver les parties lentes du programme, l'avez-vous profilé ? Laissez Devel::SmallProf faire le travail pour vous. Il compte le nombre de fois que perl exécute une ligne de code ainsi que le temps que ça prend, et affiche un joli rapport.

• Quel test plante ?

  Si vous avez une série de tests, quel test plante ? Vous devriez être capable de trouver l'erreur très rapidement, puisque chaque test ne fait travailler qu'un petit bout de code.

  Si vous n'avez pas de série de tests, pourquoi ne pas en faire une ? Je ne vais pas vous faire écrire une série de tests si vous avez vraiment un tout petit script, ou si celui-ci est jetable. Mais tout le reste ne pourra que bénéficier de quelques scripts de tests. Test::Harness rend cela si simple que vous n'avez presque aucune excuse de ne pas le faire. Si vous n'avez pas le temps, c'est peut-être parce que vous passez trop de temps à déboguer des scripts sans test. MakeMaker n'est pas que pour les modules, après tout.

• En avez-vous parlé au nounours ?

  Expliquez votre problème à voix haute. Faites vraiment des phrases.

  Pendant quelques années, j'ai eu le plaisir de travailler avec un très bon programmeur qui pouvait résoudre à peu près n'importe quoi. Quand j'étais vraiment bloqué, j'allais jusqu'à son bureau et je commençais à expliquer mon problème. En général, je ne dépassais pas la troisième phrase sans dire « Laisse tomber. J'ai compris ». Il se trompait rarement.

  Comme vous avez probablement besoin de beaucoup faire ça, je vous recommande d'utiliser un jouet en peluche comme thérapeute Perl, afin de ne pas ennuyer vos collègues. J'ai un petit ours assis sur mon bureau et à qui j'explique mes problèmes. Ma femme ne fait même plus attention quand je parle tout seul.

• Est-ce que le problème a une autre tête sur le papier ?

  Vous regardez fixement votre écran depuis trop longtemps, alors peut-être qu'un autre support vous aidera à regarder les choses autrement. Essayez de jeter un œil à une impression de votre programme.

• Avez-vous regardé Le Bigdil avec Lagaf ?

  Sérieusement. Si vous n'aimez pas Lagaf, choisissez autre chose. Faites une pause. Arrêtez de penser à ce problème pour un moment, et reposez-vous l'esprit. Revenez à ce problème plus tard, et la correction vous apparaîtra peut-être immédiatement.

• Avez-vous mis votre ego de côté ?

  Si vous n'y êtes toujours pas arrivé à ce point, le problème est peut-être psychologique. Vous vous êtes éventuellement attaché à une certaine partie du code, et vous ne la changez pas. Vous pensez peut-être aussi que tout le monde se trompe sauf vous. Quand vous réfléchissez comme ça, vous négligez sérieusement la cause la plus probable de bogues : vous-même. Ne négligez rien. Vérifiez tout.

Copyright © Les Mongueurs de Perl, 2001-2011 pour le site.
Les auteurs conservent le copyright de leurs articles.