%%  Format et mise en page 

\def\presentation{
\voffset -.50in  \hoffset -.19in
\oddsidemargin 0in \evensidemargin 0in
\marginparwidth .75in \marginparsep 7pt \topmargin 0in
\headheight 12pt \headsep .25in
\footheight 18pt \footskip .35in
\textheight 9.5in \textwidth 6.5in
\columnsep 10pt \columnseprule 0pt }

\def\program#1{{\it{#1}}}
\def\programwithlink#1#2{{\it{{#1}/{#2}}}}
\def\href#1#2{#1\footnote{#2}}
\def\option#1{-#1}
\def\longoption#1{- -#1}
\def\filename#1{{\bf{#1}}}
\def\filepath#1{{\bf{#1}}}

\def\bookref#1{{\it{#1}}}
\def\errormessage#1{{\it{#1}}}
\def\directoryname#1{{\it{#1}}}
\def\command#1{{\it{#1}}}
\def\codeline#1{{\it{#1}}}
\def\function#1{{\it{#1}}}
\def\alert#1{{\bf{#1}}}
\def\commandarray#1{\begin{center}{\it{#1}}\end{center}}
\def\paperwithlink#1#2{{\it{#1}}}
\def\equline#1{\begin{math}#1\end{math}}

\documentclass[a4paper,11pt,twoside,openright]{book}
\voffset -.50in  \hoffset -.19in
\oddsidemargin 0in \evensidemargin 0in
\marginparwidth .75in \marginparsep 7pt \topmargin 0in
\headheight 12pt \headsep .25in
\textheight 9.5in \textwidth 6.5in
\columnsep 10pt \columnseprule 0pt 

\usepackage[francais]{babel}
\usepackage[french]{minitoc}
\usepackage{longtable}

\begin{document}


\setcounter{chapter}{6}

\chapter{Hygi\`ene et programmation: les presque 10 commandements}

\section{Remarque pr\'eliminaire}


Comme nous l'avons d\'ej\`a signal\'e, ces notes offrent volontairement une vision tronqu\'ee de PERL. Mais ce chapitre est s\^urement celui qui est le plus pol\'emique. Nous allons vous pr\'esenter ce qui constitue, \alert{de notre point de vue}, les r\`egles aidant \`a la programmation. Vous n'\^etes en aucun cas oblig\'e de les suivre et si vous discutez avec d'autres programmeurs en PERL, vous pourriez m\^eme obtenir des avis allant \`a l'encontre de ceux donn\'es ici. A vous de faire votre choix et de garder ce qui vous convient. Note aux th\'esards et autres intermittents de la science: pour obtenir un poste permanent, veillez \`a ne surtout pas respecter ces commandements. votre code ne pourra \^etre utilisable et maintenu que par vous. Ainsi vous vous rendrez ainsi indispensable, ce qui garantira votre embauche.




\section{1er commandement: les warnings tu utiliseras}


Lorsque vous appelez un programme PERL mieux vaut demander d'afficher les erreurs non critiques ou avertissements (warnings). En g\'en\'eral, ces avertissements vous indiqueront ce qui est \`a coup s\^ur un probl\`eme de votre programme, sans pour autant entraver son ex\'ecution. Regardons ce petit exemple:\\

\begin{center}
\begin{longtable}{|rl|}
\hline
1.&\#!/usr/bin/perl\\
2.&\\
3.&{\textdollar}a = 1.2;\\
4.&{\textdollar}b = "test";\\
5.&{\textdollar}b += {\textdollar}a;\\
6.&print ({\textdollar}b."{\textbackslash}n");\\
\hline
\end{longtable}
\end{center}


A priori, ce programme a un petit probl\`eme d'arithm\'etique. Pourtant, aucune erreur n'est indiqu\'ee (il affiche 1.2). Si maintenant vous ajoutez un -w apr\`es la commande \command{perl} soit \`a la premi\`ere ligne du programme pour ceux qui on l'habitude de rendre leur script ex\'ecutable, soit au moment de l'ex\'ecution du script (\command{perl -w warning.pl}) soit encore via les options de votre IDE (Open-PERL-IDE, KDevelop,...), vous obtiendrez le message suivant

\begin{center}\begin{longtable}{|rl|}
\hline
&{\it Argument "test" isn't numeric in addition (+) at warning.pl line 5.}\\
&{\it 1.2}\\
\hline
\end{longtable}
\end{center}


Il est donc plus que fortement conseill\'e d'\^etre en mode warning pour \'eviter de chercher les erreurs triviales de votre programme.



\section{2\`eme commandement: des noms compr\'ehensibles \`a tes variables et fonctions tu donneras}


PERL ne poss\`ede que tr\`es peu de limitation concernant le nombre et le type de caract\`eres qui composent les noms de variables ou de fonctions. Alors n'h\'esitez pas \`a choisir ces derniers de la fa\c{c}on la plus explicite possible, surtout s'il s'agit de variables non triviales ou cruciales. Certes, certains pourront se moquer de vos noms \`a rallonge. Mais si vous devez vous replonger dans un code plusieurs mois apr\`es l'avoir \'ecrit, ces railleries vous sembleront d\'erisoires compar\'ees \`a l'avantage que cela vous procure.

En particulier, un nom peut tr\`es bien \^etre compos\'e de plusieurs mots. Il existe plusieurs techniques pour s\'eparer ces mots: vous pouvez utiliser le caract\`ere soulign\'e \_ ou la notation hongroise (chaque mot commen\c{c}ant par une majuscule). Eviter aussi les abr\'eviations: si elles sont \'evidentes pour vous, elles ne le seront pas forc\'ement pour celui qui reprendra votre programme dans trois ans.



\section{3\`eme commandement: les valeurs en dur tu \'eviteras}


Un programme PERL a souvent besoin d'information concernant des noms de fichiers, des tailles, des cha\^{\i}nes de caract\`eres ... La tendance naturelle est d'\'ecrire ces informations directement dans le script. Cela constitue la pire des techniques. Il n'est pas rare de vouloir changer un param\`etre et il faut dans ce cas l\`a \'editer le script, rep\'erer tous les endroits o\`u ce param\`etre apparait ... L'id\'eal est donc de fournir ces informations au moment de l'ex\'ecution, en utilisant \codeline{STDIN} pour demander \`a l'utilisateur, \codeline{@ARGV}, voire dans certains cas un fichier de configuration qui sera analys\'e au d\'ebut de l'ex\'ecution de votre programme (apr\`es tout, l'analyse de texte est un domaine dans lequel PERL excelle).

Au pire, veillez \`a regrouper ces quelques param\`etres au d\'ebut du programme o\`u vous les stockerez dans des variables ad\'equates. La meilleure technique est en fait de tout mettre dans une table de hash, ce qui permet de manipuler un seul objet contenant toute la configuration.



\section{4\`eme commandement: des fonctions tu abuseras}


Comme votre principale activit\'e (hormis pour certains acharn\'es) est la physique, moins vous passerez de temps \`a programmer, plus la science avancera. Les fonctions ont plusieurs avantages. Elles forment des morceaux de code test\'es que vous pourrez tr\`es facilement r\'eutiliser. Elles permettent d'\'eviter la redondance de code toujours sujette \`a des bugs plus importants (corrections ou modifications que vous oubliez de r\'epercuter dans les autres blocs). Elles facilitent aussi la lecture du code \'evitant d'\^etre distrait par des parties non sensibles de l'algorithme. En bref les fonctions sont vos alli\'es les plus puissantes, servez-vous en.


\section{5\`eme commandement: tes fonctions tu documenteras}


Vouloir r\'eutiliser des fonctions est une id\'ee louable qui peut malheureusement tourner au cauchemar si vous ne les avez pas document\'ees. Les commentaires \`a l'int\'erieur de la fonction elle-m\^eme  ne sont pas en g\'en\'eral les plus utiles: si vous devez vous plonger dans le corps de la fonction proprement dit pour pouvoir l'utiliser, ce qui n\'ecessite beaucoup de temps, vous ne gagnerez rien. De plus, un programme bien cod\'e ne n\'ecessite que peu de commentaires pour \^etre compr\'ehensible.

Il est important de documenter la fonction de telle sorte que vous puissiez savoir imm\'ediatement comment l'utiliser, c'est \`a dire ce qu'elle fait, quels sont les param\`etres \`a passer et que retourne votre fonction. Voici une fa\c{c}on parmi d'autres de r\'ediger une documentation minimaliste:\\

\begin{center}
\begin{longtable}{|rl|}
\hline
1.&\# fonction qui additionne deux nombres\\
2.&\#\\
3.&\# {\textdollar}\_[0] = premier nombre\\
4.&\# {\textdollar}\_[1] = deuxieme nombre\\
5.&\# valeur de retour = somme des deux nombres\\
6.&\\
7.&sub Addition\\
8.&\hspace{0.25cm}\{\\
9.&\hspace{0.5cm}return ({\textdollar}\_[0] + {\textdollar}\_[1]);\\
10.&\hspace{0.25cm}\}\\
\hline
\end{longtable}
\end{center}


Certes, cet exemple est un peu pathologique (vous vous doutez bien de ce qu'il faut passer et ce que la fonction va retourner) mais en r\`egle g\'en\'erale cela vous \'evitera une \'enorme perte de temps. M\^eme sur une fonction aussi petite, ayez le r\'eflexe de documenter: c'est une bonne habitude \`a prendre. N'h\'esitez pas \`a indiquer d'\'eventuelles contraintes sur les param\`etres d'entr\'ee et la valeur de retour afin d'\'eviter tout comportement anormal avec un mauvais jeu d'arguments.


\section{6\`eme commandement: les variables par d\'efaut tu banniras}


M\^eme si il est possible de trouver pratique les variables par d\'efaut, elles peuvent \^etre source d'erreur et dans tous les cas, rendent votre code moins lisible (surtout pour les non-initi\'es). En particulier, dans une fonction, nous conseillons vivement dans les premi\`eres lignes de celles-ci, de r\'ecup\'erer les arguments qui ont \'et\'e plac\'es dans le tableau par d\'efaut et de les placer dans des variables avec des noms explicites. Cela facilitera grandement la compr\'ehension du code de votre fonction, surtout si celle-ci d\'epasse la vingtaine de lignes.
 

\section{7\`eme commandement: les variables globales tu \'eviteras}


Les variables globales ont tendance \`a rendre votre programme plus difficile \`a maintenir d\`es qu'il atteint une certaine taille. Pour un bon usage de PERL, mieux vaut ajouter la ligne \codeline{use strict 'vars';} en d\'ebut de programme  (apr\`es la ligne d'invocation de PERL pour les unixiens/bsdiens). Ceci permet d'interdire l'usage des variables globales et n\'ecessite donc de d\'eclarer toutes les variables comme locales. L'effet de bord de l'utilisation de \codeline{strict} est que vous \'evitez le type d'erreur suivant:\\

\begin{center}
\begin{longtable}{|rl|}
\hline
1.&\#!/usr/bin/perl\\
2.&\\
3.&{\textdollar}variable = "test{\textbackslash}n";\\
4.&print ({\textdollar}varable);\\
5.&print ("erreur{\textbackslash}n");\\
\hline
\end{longtable}
\end{center}


Nous avons juste fait une faute de frappe ligne 4. Le programme n'affiche que le message \codeline{erreur}. Si maintenant vous ajoutez \codeline{use strict 'vars';}:\\

\begin{center}
\begin{longtable}{|rl|}
\hline
1.&\#!/usr/bin/perl\\
2.&\\
3.&use strict 'vars';\\
4.&\\
5.&my {\textdollar}variable = "test{\textbackslash}n";\\
6.&print ({\textdollar}varable);\\
7.&print ("erreur{\textbackslash}n");\\
\hline
\end{longtable}
\end{center}


Vous obtenez le message suivant:\\

\begin{center}\begin{longtable}{|rl|}
\hline
&{\it Global symbol "{\textdollar}varable" requires explicit package name at strict.pl line 6.}\\
&{\it Execution of strict.pl aborted due to compilation errors.}\\
\hline
\end{longtable}
\end{center}


Notez qu'un warning vous aurait aussi permis de d\'etecter cette erreur mais aurait tout de m\^eme ex\'ecut\'e le reste du programme, ce qui peut \^etre dramatique comme dans l'exemple qui suit:

\begin{center}
\begin{longtable}{|rl|}
\hline
1.&\#!/usr/bin/perl -w\\
2.&\\
3.&{\textdollar}document = "";\\
4.&open (INFILE, "test");\\
5.&while ({\textdollar}ligne = {\textless}INFILE{\textgreater})\\
6.&\hspace{0.25cm}\{\\
7.&\hspace{0.5cm}{\textdollar}ligne ={\textasciitilde} s/toto/tata/g;\\
8.&\hspace{0.5cm}{\textdollar}document .= {\textdollar}ligne;\\
9.&\hspace{0.25cm}\}\\
10.&close (INFILE);\\
11.&open (OUTFILE, "{\textgreater}test");\\
12.&print OUTFILE {\textdollar}docment;\\
13.&close (OUFILE);\\
\hline
\end{longtable}
\end{center}


Ce petit programme remplace tous les mots \codeline{toto} par \codeline{tata}. Le contenu du fichier est temporairement stock\'e dans \codeline{{\textdollar}document}. Le probl\`eme est qu'au moment de sauvegarder les modifications, nous enregistrons le contenu de \codeline{{\textdollar}docment} qui n'est pas d\'efini. Au moment de l'ex\'ecution, vous obtenez un warning mais le contenu de votre fichier est tout de m\^eme remplac\'e par du vide. Vous venez ainsi d'effacer votre fichier!  


\section{8\`eme commandement: ton programme tu a\`ereras}


Comme nous l'avons d\'ej\`a soulign\'e, PERL se moque des espaces, tabulations et autres sauts de ligne dans l'\'ecriture du programme. Il faut vraiment utiliser cet avantage pour donner un aspect visuel qui permet en un clin d'oeil de voir la structure du code. Si vous avez un bon \'editeur, l'indentation des blocs d'instructions est automatique. Cela permet en particulier de deviner directement \`a quel sous-bloc appartient une ligne d'instruction. S\'eparez nettement les fonctions les unes des autres pour bien en voir les limites. Une autre technique qui devient tr\`es utile lorsque vous utilisez des op\'erateurs est d'avoir des espaces entre les op\'erateurs et les donn\'ees. Cela vous permettra de rep\'erer plus rapidement ce que fait votre ligne de code.


\section{9\`eme commandement: des commentaires tu ajouteras?}


Vous entendrez souvent dire qu'il faut mettre des commentaires dans votre programme. Il faut distinguer ceux qui permettent de documenter le code (ceux qui apparaissent au d\'ebut des fonctions) de ceux qui sont v\'eritablement dans les blocs d'instruction. En r\`egle g\'en\'erale, si vous avez suivi les pr\'ecentes recommandations (commandement 2, 5 et 8) cela n'est vraiment pas utile sauf si certaines parties de votre code deviennent trop longues (de l'ordre de la centaine de lignes). Un commentaire peut alors permettre d'aider \`a comprendre l'articulation. Pr\'ef\'erez dans ce cas un red\'ecoupage en fonction.


\section{O\`u est pass\'e le 10\`eme commandement?}


Lorsque le Tout Puissant Tux d\'eclama les dix commandements du programmeur en PERL, le peuple trouva le dernier commandement tellement ennuyeux \`a respecter qu'il refusa de le graver dans le silicone. Les historiens s'accordent pour dire que ce commandement concernait la r\'edaction de documentation. Apr\`es tout, \`a quoi bon faire un programme si personne, ni m\^eme son concepteur apr\`es six mois de non utilisation, ne peut l'utiliser sans se plonger dans le code?

Malheureusement, c'est une t\^ache particuli\`erement ingrate, surtout quand l'informatique n'est pas votre activit\'e principale. Voil\`a pourquoi ce qui \'etait le plus important des commandements est tomb\'e dans l'oubli.




\end{document}


