Transcription

R, Bonnes pratiquesChristophe Genolini

1

Table des matières1 Des bonnes pratiques, pour quoi faire ?42 Choix de l’éditeur de texte43 Architecture du code64 Variables105 Commentaires et documentation126 Divers137 Astuces de programmation16Références182

3

1Des bonnes pratiques, pour quoi faire ?Quand les hommes ont commencé à envoyer des fusées dans l’espace 3 et qu’elles ontexplosé en plein vol, ils ont écrasé une petite larme et ont cherché les causes de l’échec.Comme il fallait bien brûler quelqu’un, ils ont cherché un coupable. Et ils ont trouvé. lesinformaticiens. “C’est pas d’not’ faute, ont déclaré les informaticiens tous marris, c’estun fait avéré intrinsèque aux ordinateurs : tous les programmes sont buggués !” Sauf quedans le cas présent, la facture du bug était plutôt salée. Des gens très forts et trèsintelligents ont donc cherché des moyens de rendre la programmation moins bugguée. Ilsont fabriqué des nouveaux langages et défini des règles de programmation. On appelleça la programmation propre ou les bonnes pratiques.Les bonnes pratiques sont des règles que le programmeur choisit de suivre pour améliorer la qualité de sa programmation et diminuer le nombre de bugs de ses programmes.Les règles que nous proposons ici sont soit adaptées des bonnes pratiques qu’on trouvedans les livres sur les langages objets, soit issues des discussions de la liste de diffusionde R [3] et du forum GuR [1], ou encore librement inspirées du document de MartinMächler [2].Avant d’entrer dans le vif du sujet, un petit avertissement : toutes ces règles et les situations qui les justifient donnent l’illusion d’être balayables d’un haussement d’épaules :“Ça, en faisant un peu attention, ça ne m’arrivera pas, pas besoin de règle.” La pratiquenous affirme l’inverse : Même en suivant les règles, on arrive tout de même à faire leserreurs qu’elles essaient de prévenir. D’où, ne vous y trompez pas, ces règles ne sont quedes petites astuces pour étourdis : bien les utiliser fera toute la différence entre le bonprogrammeur et le programmo-touriste.2Choix de l’éditeur de texte- E1 Utilisez un éditeur de texte intelligent(avec coloriage, détection des parenthèses et indentation automatique).Installer un éditeur intelligent (comme emacs ou Tinn-R) ne vous prendra pas beaucoup de temps, mais cela vous fera gagner des heures de recherche de parenthèses ou deguillemets “mal placés”.Voilà un exemple de code tiré du pacakge kml. Á gauche, il est non colorié. Où estl’erreur ?4

Á droite, le même code est colorié. On voit que dans le bas du texte, des instructionscomme cat sont dans la couleur réservée normalement au texte entre guillemets. On enconclut qu’il y a un guillement mal fermé. C’est celui du troisème cat.De même, un éditeur évolué peut détecter automatiquement les couples de parenthèses et accolades. Plus précisément, dans un langage informatique, chaque parenthèseouvrante doit être couplée à une parenthèse fermante ; même chose pour les accolades etles crochets. Un éditeur évolué a généralement la gentillesse de surligner la parenthèseouvrante correspondant à la parenthèse fermante sur laquel est positionné le curseur, etréciproquement (même chose pour les accolades ou les crochets).Ainsi, sur le code de gauche, l’accolade du bas que le programmeur pensait êtrel’accolade finale fermant la fonction s’avère fermer l’accolade du if. On peut en conclurequ’il manque l’accolade fermante du if. Sur le code de droite, l’accolage manquante aété ajoutée ; l’accolade du bas ferme bien l’accolade d’ouverture de la fonction.5

3Architecture du codeUn programme est généralement un code long et compliqué fait à partir d’instructionsrudimentaires. Une suite de 10 000 instructions rudimentaires serait incompréhensible.Il est donc courant de les “regrouper” : des instructions rudimentaires sont assembléesen bloc, les blocs sont regroupés en fonctions, les fonctions sont elles même utiliséespour d’autres fonctions et au final, le programme principal sera composé de quelquesfonctions. Ce découpage constitue “l’architecture d’un programme”. Il est important quecette architecture soit visible. Pour cela, plusieurs règles :- A1 Deux instructions distinctes doivent être sur deux lignes séparées.Pour s’en convaincre, il suffit de se demander ce que fait le code suivant :long - 13; triangleRect - function ( long ){ result - 0;f o r ( i in 1: long ){ cat ( " \ n " , rep ( " * " ,i ));result - result i }; return ( result );}Une instruction par ligne rendrait les choses bien plus lisibles :long - 13triangleRect - function ( long ){result - 0f o r ( i in 1: long ){cat ( " \ n " , rep ( " * " ,i ))result - result i }return ( result )}C’est plus lisible, mais l’architecture générale reste cachée. Pour la mettre en évidence,d’autres règles :- A2 Les lignes doivent être indentées de manière à mettreles blocs constituant le code en valeur.- A3 Chaque accolade fermante doit être verticalement alignéeà l’instruction définissant l’accolade ouvrante correspondante.Ces deux rêgles permettent la mise en évidence des blocs. Notre code devientlong - 13triangleRect - function ( long ){result - 0f o r ( i in 1: long ){6

cat ( " \ n " , rep ( " * " ,i ))result - result i}return ( result )}La structure commence à apparaitre : Au plus bas niveau (le plus décalé à droite),on distingue un bloc. Ce bloc est contenu dans une boule for. La boucle for plusl’initialisation de result sont eux-mêmes dans une fonction nommée triangleRect.Enfin, on peut marquer un peu plus l’existence de blocs ou de fonctions en sautantdes lignes :- A4 Les blocs d’instruction ou les fonctions doivent être séparés par des lignes.long - 13triangleRect - function ( long ){result - 0f o r ( i in 1: long ){cat ( " \ n " , rep ( " * " ,i ))result - result i}return ( result )}Il devient plus facile de comprendre ce que fait la fonction triangleRect : elle dessineun rectangle avec des étoiles et calcule sa surface : triangleRect (4)** ** * ** * * * [1] 10Pour certaines instructions, les accolades sont facultatives. Par exemple, quand unbloc d’instruction suit un for :f o r ( i in 1:5)cat ( " I " ,i )I 1 I 2 I 3 I 4 I 5Le résultat est le même que celui produit en utilisant le code avec accolades :f o r ( i in 1:5){cat ( " I " ,i )}I 1 I 2 I 3 I 4 I 57

Mais supposons que l’on souhaite ajouter une instruction dans la boucle. Dans lepremier cas, on obtient :f o r ( i in 1:5)cat ( " I " ,i )cat ( " I 2 " ,i 2)I 1 I 2 I 3 I 4 I 5 I 2 25Dans le deuxième :f o r ( i in 1:5){cat ( " I " ,i )cat ( " I 2 " ,i 2)}I 1 I 2 1 I 2 I 2 4 I 3 I 2 9 I 4 I 2 16 I 5 I 2 25Dans le deuxième cas, on a effectivement ajouté une instruction dans la boucle. Maisdans le premier cas, comme il n’y a pas d’accolade, la ligne ajoutée est “hors boucle”.Bien sûr, en étant attentif, on se serait rendu compte qu’il fallait ajouter les accolades.Mais les bonnes pratiques ont justement pour but de traiter les erreurs d’inattention.Omettre les accolades facultatives augmente le risque d’erreur de programmation. D’oùla règle de “prudence architecturale” :- A5 N’omettez pas les accolades facultatives.De même, le else d’une instruction if est facultatif. Mais omettre un else peutintroduire des ambiguités. En effet, considérons le codei f ( cond1 ) i f ( cond2 ) cat ( " A " ) e l s e cat ( " E " )Que veut le programmeur ? Veut-il :i f ( cond1 )i f ( cond2 )cat ( " A " )elsecat ( " E " )Ou veut-il plutôt :i f ( cond1 ){i f ( cond2 )cat ( " A " )elsecat ( " E " )8

Dans le premier cas, le else se rapporte au premier if. Dans le deuxième, le elsese rapporte au deuxième. En théorie des langages, on appelle ça une “ambiguité syntaxique” : il manque quelque chose. Bien sûr, on peut essayer et voir comment R réagit.Mais la version de R peut changer ; si vous utilisez un autre logiciel de programmation,peut-être que ce dernier se comportera différament. Bref, il vaut mieux écrire sans fairede pari sur les réactions de l’interpréteur du langage. Selon ce que l’on souhaite :i f ( cond1 ){i f ( cond2 ){cat ( " A " )} else {cat ( " E " )}} else {}oui f ( cond1 ){i f ( cond2 ){cat ( " A " )} else {}} else {cat ( " E " )}Il n’y a plus d’ambiguité. D’où la rêgle de désambiguiation :- A6 Toutes les conditions doivent comporter un else,même s’il est vide.En France, après un examen, les possibilités sont les suivantes : si vous avez moinsde 8, vous avez échoué. Si vous avez plus de 10, vous êtes reçu. Si vous avez entre 8 et10, vous pouvez présenter un oral de rattrapage deux semaines plus tard. Qu’est-ce quiest faux dans le code suivant ?f o r ( x in 1:100){ i f ( note [ x ] 10){ i f ( note [ x ] 8){ cat ( " Fail " )} e l s e { cat ( " You get it " )}}Voilà le même code après application des règles précédentes :9

f o r ( x in 1:100){i f ( note [ x ] 10){i f ( note [ x ] 8){cat ( " Fail " )} else {cat ( " You get it " )}}Les erreurs sont bien plus facilement identifiables :– Il manque une accolade– Il n’y a qu’un seul else pour deux if. Le else{cat("You get it !")} est utiliséà la mauvaise place.Le code correct est donc :f o r ( x in 1:100){i f ( note [ x ] 10){i f ( note [ x ] 8){cat ( " Fail " )} e l s e {}} else {cat ( " You get it " )}}4VariablesLes variables constituent généralement le cœur d’un programme. Bien les nommer estfondamental. Par exemple, que fait le code suivant ? Y a-t-il des bugs ? Que représentem? n - c (9 ,18 ,5 ,14)a - c (17 ,18 ,18 ,17)nn - 4( m - sum ( n ) / a )[1] 2.705882 2.555556 2.555556 2.705882Mêmes questions avec le code suivant : noteEleves - c (9 ,18 ,5 ,14)ageEleves - c (17 ,18 ,18 ,17)nombreEleves - 4( moyenneNotes - sum ( noteEleves ) / ageEleves )[1] 2.705882 2.555556 2.555556 2.705882Comme vous pouvez le constater, le résultat final est le même. Mais dans le premiercas, on ne sait pas ce que sont m, n et a ; dans le deuxième, non seulement on sait de10

quoi il retourne (selon toute vraisemblance, moyenneNotes est utilisée pour calculer lamoyenne des notes des élèves), mais il est clair que le résultat devrait être un nombreunique et non un vecteur. Il serait également surprenant qu’une moyenne de notes tourneautour de 2.6. L’erreur est facilement identifiable : la somme des notes des élèves a étédivisée par les âges au lieu du nombre d’élèves. D’où l’importance de bien choisir le nomdes variables.La première régle est celle que notre exemple vient de mettre en évidence :- V1 Nommez vos variables explicitementUne manière de faire est de choisir pour nom une suite de mots décrivant la variablemais sans les séparer par des espaces. Pour plus de lisibilité, chaque mot commence parune majuscule sauf le premier. Par exemple, nombreDeFils, noteEleves ou ageElevessont des noms explicites dont la lecture explique le contenu.Le côté “explicite” n’est cependant pas le seul à considérer. En effet, des noms devariables trop longs nous obligeraient à écrire un code sur plusieur lignes. Les instructionsdu langage seraient alors noyées, cela rendrait le code illisible : n o t e s D e s E l e v e s D u G r o u p e D e T r a v a u x D i r i g e s 6 - c (9 ,18 ,5 ,14)n o m b r e D E l e v e s D u G r o u p e D e T r a v a u x D i r i g e s 6 - 4( m o y e n n e D e s N o t e s D u G r o u p e D e T r a v a u x D i r i g e s 6 sum ( n o t e s D e s E l e v e s D u G r o u p e D e T r a v a u x D i r i g e s 6 ) evesDuGroupeDeTravauxDiriges6 est clairement trop long. mais ndedgdtd6(uniquement les initiales de la variable précédente) n’est pas explicite. D’où un raffinement de la règle V1 :- V2 Cherchez un compromis :les noms de variables doivent être de taille raisonnable.tout en restant explicites.La majorité des langages sont sensibles à la case (ils font la distinction les majusculesdes minuscules). Il est possible d’utiliser cette propriété pour distinguer les variables, lesfonctions et les classes. Dans ce tutorial, nous avons utilisé le principe suivant :- V3 Utilisez des noms commençant par une majuscule pour les classespar une minuscule pour les variables et les fonctionsBien sûr, des variantes sont possibles. En particulier, si vous n’utilisez pas la programmation objet 1 , vous pouvez commencer vos variables par une minuscule et distinguervos fonctions par une majuscule.1. Ce conseil peut paraı̂tre étrange dans un livre dédié à la programmation objet. Mais nous noussommes laissé dire que ce manuel était aussi utilisé par des lecteurs intéressés uniquement par la construction de package classique et par les bonnes pratiques.11

Variante : la notation HongoiseIl est également possible de nommer les variables en commençant par une lettre quidonne leur type : par exemple, le nombre d’enfants est une variable entière (integer),la taille est un numérique (numeric) et la corrélation des valeurs propres d’une échellede mesure est une matrice (matrix). Ces trois variables seraient donc nommées iNombreFils, nTaille et mCorEchelle. Pour un langage non typé comme R, cela présenteun intérêt certain.Concernant les noms de variables et fonctions, il est préférable que chacun ait unusage unique :- V4 Un même nom ne doit jamais avoir deux usagesNous l’avions déjà évoqué lors de la nomenclature du constructeur d’une classe maisle principe est généralisable. En particulier, des lettres comme c et t sont des fonctionsR. Il est déconseillé de les utiliser pour stocker des valeurs (même si cela ne vous seraitpas venu à l’esprit en vertu des règles V1 et V2 ?)De même, il est peu souhaitable d’utiliser le même nom pour une fonction et pourun des arguments de la fonction. Par exemple, il serait maladroit de définir la fonctionsalaire :salaire - function ( salaire ){cat ( " Salaire horaire " , salaire / 35)}5Commentaires et documentationUn programme est quelque chose de compliqué. Les commentaires permettent d’enfaciliter la lecture.- C1 Commentez votre code.Les commentaires servent à écrire en français ce que le programme fait. On peutainsi suivre son évolution calculs plus facilement. L’art du commentaire n’est pas aisé :en particulier, il ne faut pas trop “coller” au programme, tout en restant explicite. Parexemple, dans # ## Affecte 2 à i i - 2le commentaire ne sert strictement à rien.- C2 Commentez votre code intelligemment.12

Les commentaires peuvent intervenir au niveau local, mais également global. En effet,un utilisateur (vous-même six mois plus tard) doit pouvoir utiliser votre fonction sansavoir à lire le code. Il est donc capital de bien préciser les variables à fournir en entréeet ce qu’il récupèrera à la sortie.- C3 Documentez les entrées et sorties de chaque fonction / méthode.Exemple, le package kml définit plusieurs fonctions qui travaillent sur des trajectoires.L’une d’entre elles les impute. Voilà ce qu’on peut lire dans le code :# ## imputeTraj needs two arguments# ## - matrixToImpute is a matrix with or without missing values# ## - method is a character string in " LOCF " , " mean " , " multiple "# ### ## ImputeTraj returning a matrix without missing values# ##imputeTraj - function ( matrixToImpute , method ){.return ( matrixImputed )}Même sans lire le code, on sait ce que cette fonction prend comme argument etretourne comme valeur.6DiversL’initialisation par défaut n’a plus vraiment de raison d’être.- D1 N’utilisez pas de valeurs par défaut :Une variable non initialisée doit provoquer une erreur.En particulier, dans un langage statistique comme R, les valeurs manquantes jouenten rôle important (hélas !). Une initialisation malencontreuse peut fausser le résultat.Dans le code suivant, on initie la variable age à zéro, puis on la modifie ensuite aufûr et à mesure qu’on reçoit de l’information : # ## Liste de nomdata - data . frame ( nom c ( " Renée " ," Marcel " ," Raymonde " ," Isidore " ))# ## Initialisation avec la valeur 0data age - 0# ## Renseignement des lignes " au fur et à mesure "data age [1] - 43data age [3] - 56data age [4] - 51# ## Calcul de la moyennemean ( data age )[1] 37.513

Bien évidemment, le calcul de la moyenne est faux puisque l’âge de Marcel n’a pas étérenseigné. La non-initialisation de la variable age (ou plus exactement son initialisationà NA) aurait permis d’éviter l’erreur : # ## Liste de nomdata - data . frame ( nom c ( " Renée " ," Marcel " ," Raymonde " ," Isidore " ))# ## Initialisation avec la valeur NAdata age - NA# ## Renseignement des lignesdata age [1] - 43data age [3] - 56data age [4] - 51# ## Calcul de la moyennemean ( data age )[1] NA- D2 Dans l’appel d’une fonction, spécifiez les arguments par leur nom.Ne pas respecter cette règle, c’est s’exposer à intervertir involontairement l’ordre desarguments : # ## Définition de la fonction IMCIMC - function ( taille , poids ){return ( poids / taille 2)}# ## Mes paramètresmonPoids - 86maTaille - 1.80# ## Mon IMC sans specifier le nom des argumentsIMC ( monPoids , maTaille )[1] 0.0002433748 # ## Mon IMC en specifiant le nom des arguments IMC ( poids monPoids , taille maTaille )[1] 26.54321- D3 N’utilisez jamais de variable globale.Jamais.Une variable globale est une variable qui est définie à l’extérieur d’une fonction. Dèslors, l’utilisation de la fonction dépend d’autre chose que d’elle-même.Or, le principe préludant à la construction d’une fonction est le même que celui d’uneméthode : elle doit être automome, ne pas avoir besoin de l’environnement global. Unefois terminé, le programmeur ne doit plus avoir besoin de lire son code. Une fonction doit14

pouvoir fonctionner même si son environnement change. En particulier, si vous copiercoller votre fonction dans un autre programme, elle doit fonctionner sans aménagement.Dans l’exemple suivant, la fonction définie n’est utilisable que pour moi et non pourlui : # ## VariablesmesAnneesDEtude - 8monSalaire - 2500sesAnneesDEtude - 5sonSalaire - 3300# ## Variation sur salaire# ##la variable mesAnneesDEtude est globalesalaireDetail - function ( salaire ){cat ( " Salaire horaire " , salaire / 35)cat ( " \ nRentabilité des études " , salaire / mesAnneesDEtude )}# ## Pour moisalaireDetail ( salaire monSalaire )Salaire horaire 71.42857Rentabilité des études 312.5 # ## Pour lui salaireDetail ( salaire sonSalaire )Salaire horaire 94.28571Rentabilité des études 412.5Aucune erreur n’est signalée. Et pourtant, le calcul de Rentabilite pour lui estfaux. # ## VariablesmesAnneesDEtude - 8monSalaire - 2500sesAnneesDEtude - 5sonSalaire - 3300# ## Variation sur salaire# ##la variable mesAnneesDEtude est globalesalaireDetail - function ( salaire , anneesDEtude ){cat ( " Salaire horaire " , salaire / 35)cat ( " \ nRentabilité des études " , salaire / anneesDEtude )}# ## Pour moisalaireDetail ( salaire monSalaire , anneesDEtude mesAnneesDEtude )Salaire horaire 71.42857Rentabilité des études 312.5 # ## Pour lui salaireDetail ( salaire sonSalaire , anneesDEtude sesAnneesDEtude )Salaire horaire 94.28571Rentabilité des études 66015

- D4 N’utilisez pas d’abréviation.Par exemple, utilisez FALSE / TRUE et non 0 / 1 ou F / T. Les abréviations diminuentla lisibilité du code.Enfin, tout règlement qui se respecte devrait comporter une clause précisant de nepas trop respecter le règlement (sinon, gare au fanatisme.)- D5 La clartée doit primer sur le respect des règles.Si dans un cas particulier, une règle nuit à la lisibilité, ignorez-la !Par exemple, plusieurs instructions if successives peuvent être plus lisibles si on lesnote sur une ligne unique. En respectant les règles :setReplaceMethod( " [ " ," ClusterizLongData " ,function (x ,i ,j , value ){i f ( i " id " ){[email protected] - value} else {}i f ( i " var " ){[email protected] - value} else {}i f ( i " name " ){[email protected] - value} else {}})Le code plus lisible quand on applique la règle D5 :setReplaceMethod( " [ " ," ClusterizLongData " ,function (x ,i ,j , value ){i f ( i " id " ){ [email protected] - value } e l s e {};i f ( i " var " ){ [email protected] - value } e l s e {};i f ( i " name " ){ [email protected] - value } e l s e {};})7Astuces de programmationEnfin, voilà quelques astuces de programmation. Ce ne sont pas à précisément parlerdes bonnes pratiques, elles rentrent plus dans la catégorie des méthodes de programmation liées aux spécificités de R.16

1. Testez votre code. Testez votre code régulièrement, n’écrivez pas un long code pourne le tester qu’à la fin, cela rendrait le débuggage très difficile.2. Écrivez de nombreuses petites fonctions et testez-les au fur et à mesure.3. N’utilisez pas x[ind,], remplacez-le par x[ind,drop FALSE].4. N’utilisez pas x NA, remplacez-le par is.na(x).5. N’utilisez pas 1:length(x), remplacez-le par seq(along x).6. N’attachez pas vos data.frame à l’environnement (cela les tranformerait en variables globales, infraction D3).7. N’utilisez pas pour vos affectations, remplacez-le par -.8. N’essayez pas d’écrire un code optimal. Écrivez un code clair et simple. Plus tard,quand votre code sera opérationnel, bien plus tard, il sera temps de penser àl’optimisation.9. Les boucles ne sont pas efficaces dans R. Il est préférable de les remplacer par lesfonctions lapply et sapply.Concernant les tests réguliers, il est plus facile de tester une fonction qu’une méthode.Aussi, il est plus simple de déclarer la fonction utilisée par une méthode à part. On vérifieensuite qu’elle fonctionne correctement puis on l’intègre dans la méthode. Enfin, une foisla méthode déclarée, la fonction peut être supprimée sans que cela n’affecte la méthode.A quoi bon la supprimer, diriez-vous ? C’est simplement pour ne pas laisser “trainer”dans l’espace de travail des variables, fonctions ou objets qui ne seront plus utilisées.C’est un peu comme passer l’éponge sur la table après le petit déjeuner pour enlever lesmiettes. De manière générale, plus c’est propre, moins il y a de bugs.Donc, au lieu de : setMethod( f " methodA " , signature " clasA " , d e f i n i t i o n function (){ cat ( " Bonjour le monde " ) return ( invisible ()) } )on peut écrire : # ## Définition de la fonction. clasA . methodA - function (){cat ( " Bonjour le monde " )return ( invisible ())}# ## Ici , on teste . clasA . methodA :# ##- recherche des bugs# ##- detection des variables globales avec findGlobals# ##- tests préliminaires# ##- .# ## Ensuite , définition de la méthode17

setMethod(f " methodA " ,signature " clasA " ,d e f i n i t i o n . clasA . methodA)# ## Puis nétoyagerm (. clasA . methodA )Références[1] CIRAD. GuR : Groupe des Utilisateurs de R, 2004http://forums.cirad.fr/logiciel-R.[2] M. Mächler. Good Programming Practice, 04/Keynotes/Maechler.pdf.[3] R-Core Team. Liste de diffusion,mailto:[email protected]

dans les livres sur les langages objets, soit issues des discussions de la liste de di usion de R [3] et du forum GuR [1], ou encore librement inspir ees du document de Martin M achler [2]. Avant d’entrer dans le vif du suje