R, Bonnes pratiques

Christophe Genolini

Table des mati`res e

1 Des bonnes pratiques, pour quoi faire ? 2 Choix de lditeur de texte e 3 Architecture du code 4 Variables 5 Commentaires et documentation 6 Divers 7 Astuces de programmation Rfrences ee 4 4 6 10 12 13 16 18

Des bonnes pratiques, pour quoi faire ?

Quand les hommes ont commenc ` envoyer des fuses dans lespace 3 et quelles ont ea e explos en plein vol, ils ont cras une petite larme et ont cherch les causes de lchec. e e e e e Comme il fallait bien brler quelquun, ils ont cherch un coupable. Et ils ont trouv... les u e e informaticiens. Cest pas dnot faute, ont dclar les informaticiens tous marris, cest e e un fait avr intrins`que aux ordinateurs : tous les programmes sont buggus ! Sauf que ee e e dans le cas prsent, la facture du bug tait plutt sale... Des gens tr`s forts et tr`s e e o e e e intelligents ont donc cherch des moyens de rendre la programmation moins buggue. Ils e e ont fabriqu des nouveaux langages et dni des r`gles de programmation. On appelle e e e a la programmation propre ou les bonnes pratiques. c Les bonnes pratiques sont des r`gles que le programmeur choisit de suivre pour ame e liorer la qualit de sa programmation et diminuer le nombre de bugs de ses programmes. e Les r`gles que nous proposons ici sont soit adaptes des bonnes pratiques quon trouve e e dans les livres sur les langages objets, soit issues des discussions de la liste de diusion de R [3] et du forum GuR [1], ou encore librement inspires du document de Martin e Mchler [2]. a Avant dentrer dans le vif du sujet, un petit avertissement : toutes ces r`gles et les sie tuations qui les justient donnent lillusion dtre balayables dun haussement dpaules : e e Ca, en faisant un peu attention, ca ne marrivera pas, pas besoin de r`gle. La pratique e nous arme linverse : Mme en suivant les r`gles, on arrive tout de mme ` faire les e e e a erreurs quelles essaient de prvenir. Do`, ne vous y trompez pas, ces r`gles ne sont que e u e des petites astuces pour tourdis : bien les utiliser fera toute la dirence entre le bon e e programmeur et le programmo-touriste...

Choix de lditeur de texte e

- E1 Utilisez un diteur de texte intelligent e (avec coloriage, dtection des parenth`ses et indentation automatique). e e

Installer un diteur intelligent (comme emacs ou Tinn-R) ne vous prendra pas beaue coup de temps, mais cela vous fera gagner des heures de recherche de parenth`ses ou de e guillemets mal placs... e Voil` un exemple de code tir du pacakge kml. A gauche, il est non colori. O` est a e e u lerreur ?

 A droite, le mme code est colori. On voit que dans le bas du texte, des instructions e e comme cat sont dans la couleur rserve normalement au texte entre guillemets. On en e e conclut quil y a un guillement mal ferm... Cest celui du trois`me cat. e e De mme, un diteur volu peut dtecter automatiquement les couples de parene e e e e th`ses et accolades. Plus prcisment, dans un langage informatique, chaque parenth`se e e e e ouvrante doit tre couple ` une parenth`se fermante ; mme chose pour les accolades et e e a e e les crochets. Un diteur volu a gnralement la gentillesse de surligner la parenth`se e e e e e e ouvrante correspondant ` la parenth`se fermante sur laquel est positionn le curseur, et a e e rciproquement (mme chose pour les accolades ou les crochets). e e

Ainsi, sur le code de gauche, laccolade du bas que le programmeur pensait tre e laccolade nale fermant la fonction sav`re fermer laccolade du if. On peut en conclure e quil manque laccolade fermante du if. Sur le code de droite, laccolage manquante a t ajoute ; laccolade du bas ferme bien laccolade douverture de la fonction. ee e

Architecture du code

Un programme est gnralement un code long et compliqu fait ` partir dinstructions e e e a rudimentaires. Une suite de 10 000 instructions rudimentaires serait incomprhensible. e Il est donc courant de les regrouper : des instructions rudimentaires sont assembles e en bloc, les blocs sont regroups en fonctions, les fonctions sont elles mme utilises e e e pour dautres fonctions et au nal, le programme principal sera compos de quelques e fonctions. Ce dcoupage constitue larchitecture dun programme. Il est important que e cette architecture soit visible. Pour cela, plusieurs r`gles : e - A1 Deux instructions distinctes doivent tre sur deux lignes spares. e e e Pour sen convaincre, il sut 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 <- 13 triangleRect <- function ( long ){ result <- 0 f o r ( i in 1: long ){ cat ( " \ n " , rep ( " * " ,i )) result <- result + i } return ( result )}

Cest plus lisible, mais larchitecture gnrale reste cache. Pour la mettre en vidence, e e e e dautres r`gles : e - A2 Les lignes doivent tre indentes de mani`re ` mettre e e e a les blocs constituant le code en valeur. - A3 Chaque accolade fermante doit tre verticalement aligne e e ` linstruction dnissant laccolade ouvrante correspondante. a e Ces deux rgles permettent la mise en vidence des blocs. Notre code devient e e
long <- 13 triangleRect <- function ( long ){ result <- 0 f o r ( i in 1: long ){

cat ( " \ n " , rep ( " * " ,i )) result <- result + i } return ( result ) }

La structure commence ` apparaitre : Au plus bas niveau (le plus dcal ` droite), a e ea on distingue un bloc. Ce bloc est contenu dans une boule for. La boucle for plus linitialisation de result sont eux-mmes dans une fonction nomme triangleRect. e e Enn, on peut marquer un peu plus lexistence de blocs ou de fonctions en sautant des lignes : - A4 Les blocs dinstruction ou les fonctions doivent tre spars par des lignes. e e e
long <- 13 triangleRect <- function ( long ){ result <- 0 f 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 dessine un rectangle avec des toiles et calcule sa surface : e
> triangleRect (4) * * * * * * * * * * [1] 10

Pour certaines instructions, les accolades sont facultatives. Par exemple, quand un bloc dinstruction suit un for :
f o r ( i in 1:5) cat ( " I = " ,i ) I= 1 I= 2 I= 3 I= 4 I= 5

Le rsultat est le mme que celui produit en utilisant le code avec accolades : e e
f o r ( i in 1:5){ cat ( " I = " ,i ) } I= 1 I= 2 I= 3 I= 4 I= 5

Mais supposons que lon souhaite ajouter une instruction dans la boucle. Dans le premier 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= 25

Dans le deuxi`me : e
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= 25

Dans le deuxi`me cas, on a eectivement ajout une instruction dans la boucle. Mais e e dans le premier cas, comme il ny a pas daccolade, la ligne ajoute est hors boucle. e Bien sr, en tant attentif, on se serait rendu compte quil fallait ajouter les accolades. u e Mais les bonnes pratiques ont justement pour but de traiter les erreurs dinattention. Omettre les accolades facultatives augmente le risque derreur de programmation. Do` u la r`gle de prudence architecturale : e - A5 Nomettez pas les accolades facultatives. De mme, le else dune instruction if est facultatif. Mais omettre un else peut e introduire des ambiguits. En eet, considrons le code e e
i 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 " ) else cat ( " E " )

Ou veut-il plutt : o
i f ( cond1 ){ i f ( cond2 ) cat ( " A " ) else cat ( " E " )

Dans le premier cas, le else se rapporte au premier if. Dans le deuxi`me, le else e se rapporte au deuxi`me. En thorie des langages, on appelle ca une ambiguit syntaxie e e que : il manque quelque chose. Bien sr, on peut essayer et voir comment R ragit. u e Mais la version de R peut changer ; si vous utilisez un autre logiciel de programmation, peut-tre que ce dernier se comportera dirament. Bref, il vaut mieux crire sans faire e e e de pari sur les ractions de linterprteur du langage. Selon ce que lon souhaite : e e
i f ( cond1 ){ i f ( cond2 ){ cat ( " A " ) } else { cat ( " E " ) } } else { }

ou
i f ( cond1 ){ i f ( cond2 ){ cat ( " A " ) } else { } } else { cat ( " E " ) }

Il ny a plus dambiguit. Do` la rgle de dsambiguiation : e u e e - A6 Toutes les conditions doivent comporter un else, mme sil est vide. e En France, apr`s un examen, les possibilits sont les suivantes : si vous avez moins e e de 8, vous avez chou. Si vous avez plus de 10, vous tes reu. Si vous avez entre 8 et e e e c 10, vous pouvez prsenter un oral de rattrapage deux semaines plus tard. Quest-ce qui e est 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 mme code apr`s application des r`gles prcdentes : a e e e e e

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 identiables : Il manque une accolade Il ny a quun seul else pour deux if. Le else{cat("You get it !")} est utilis e a ` 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 " ) } }

Variables

Les variables constituent gnralement le cur dun programme. Bien les nommer est e e fondamental. Par exemple, que fait le code suivant ? Y a-t-il des bugs ? Que reprsente e m?
> > > > 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.705882

Mmes questions avec le code suivant : e

> > > > 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.705882

Comme vous pouvez le constater, le rsultat nal est le mme. Mais dans le premier e e cas, on ne sait pas ce que sont m, n et a ; dans le deuxi`me, non seulement on sait de e 10

quoi il retourne (selon toute vraisemblance, moyenneNotes est utilise pour calculer la e moyenne des notes des l`ves), mais il est clair que le rsultat devrait tre un nombre ee e e unique et non un vecteur. Il serait galement surprenant quune moyenne de notes tourne e autour de 2.6. Lerreur est facilement identiable : la somme des notes des l`ves a t ee ee divise par les ges au lieu du nombre dl`ves. Do` limportance de bien choisir le nom e a ee u des variables. La premi`re rgle est celle que notre exemple vient de mettre en vidence : e e e - V1 Nommez vos variables explicitement Une mani`re de faire est de choisir pour nom une suite de mots dcrivant la variable e e mais sans les sparer par des espaces. Pour plus de lisibilit, chaque mot commence par e e une majuscule sauf le premier. Par exemple, nombreDeFils, noteEleves ou ageEleves sont des noms explicites dont la lecture explique le contenu. Le ct explicite nest cependant pas le seul ` considrer. En eet, des noms de oe a e variables trop longs nous obligeraient ` crire un code sur plusieur lignes. Les instructions ae du langage seraient alors noyes, cela rendrait le code illisible : e
> > > + + + 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 ) / nombreDElevesDuGroupeDeTravauxDiriges6 )

notesDesElevesDuGroupeDeTravauxDiriges6 est clairement trop long... mais ndedgdtd6 (uniquement les initiales de la variable prcdente) nest pas explicite. Do` un ranee e u ment de la r`gle V1 : e - V2 Cherchez un compromis : les noms de variables doivent tre de taille raisonnable... e tout en restant explicites. La majorit des langages sont sensibles ` la case (ils font la distinction les majuscules e a des minuscules). Il est possible dutiliser cette proprit pour distinguer les variables, les ee fonctions et les classes. Dans ce tutorial, nous avons utilis le principe suivant : e - V3 Utilisez des noms commenant par une majuscule pour les classes c par une minuscule pour les variables et les fonctions Bien sr, des variantes sont possibles. En particulier, si vous nutilisez pas la programu mation objet 1 , vous pouvez commencer vos variables par une minuscule et distinguer vos fonctions par une majuscule.
1. Ce conseil peut para tre trange dans un livre ddi a la programmation objet. Mais nous nous e e e ` sommes laiss dire que ce manuel tait aussi utilis par des lecteurs intresss uniquement par la construce e e e e tion de package classique et par les bonnes pratiques...

11

Variante : la notation Hongoise Il est galement possible de nommer les variables en commenant par une lettre qui e c donne leur type : par exemple, le nombre denfants est une variable enti`re (integer), e la taille est un numrique (numeric) et la corrlation des valeurs propres dune chelle e e e de mesure est une matrice (matrix). Ces trois variables seraient donc nommes iNome breFils, nTaille et mCorEchelle. Pour un langage non typ comme R, cela prsente e e un intrt certain. ee Concernant les noms de variables et fonctions, il est prfrable que chacun ait un ee usage unique : - V4 Un mme nom ne doit jamais avoir deux usages e Nous lavions dj` voqu lors de la nomenclature du constructeur dune classe mais eae e le principe est gnralisable. En particulier, des lettres comme c et t sont des fonctions e e R. Il est dconseill de les utiliser pour stocker des valeurs (mme si cela ne vous serait e e e pas venu ` lesprit en vertu des r`gles V1 et V2 ?) a e De mme, il est peu souhaitable dutiliser le mme nom pour une fonction et pour e e un des arguments de la fonction. Par exemple, il serait maladroit de dnir la fonction e salaire :
salaire <- function ( salaire ){ cat ( " Salaire horaire = " , salaire / 35) }

Commentaires et documentation

Un programme est quelque chose de compliqu. Les commentaires permettent den e faciliter la lecture. - C1 Commentez votre code. Les commentaires servent ` crire en franais ce que le programme fait. On peut a e c ainsi suivre son volution calculs plus facilement. Lart du commentaire nest pas ais : e e en particulier, il ne faut pas trop coller au programme, tout en restant explicite. Par exemple, dans
> # ## Affecte 2 ` i a > i <- 2

le commentaire ne sert strictement ` rien... a - C2 Commentez votre code intelligemment. 12

Les commentaires peuvent intervenir au niveau local, mais galement global. En eet, e un utilisateur (vous-mme six mois plus tard) doit pouvoir utiliser votre fonction sans e avoir ` lire le code. Il est donc capital de bien prciser les variables ` fournir en entre a e a e et ce quil rcup`rera ` la sortie. e e a - C3 Documentez les entres et sorties de chaque fonction / mthode. e e Exemple, le package kml dnit plusieurs fonctions qui travaillent sur des trajectoires. e Lune dentre elles les impute. Voil` ce quon peut lire dans le code : a
# ## 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 ) }

Mme sans lire le code, on sait ce que cette fonction prend comme argument et e retourne comme valeur.

Divers
Linitialisation par dfaut na plus vraiment de raison dtre. e e - D1 Nutilisez pas de valeurs par dfaut : e Une variable non initialise doit provoquer une erreur. e

En particulier, dans un langage statistique comme R, les valeurs manquantes jouent en rle important (hlas !). Une initialisation malencontreuse peut fausser le rsultat. o e e Dans le code suivant, on initie la variable age ` zro, puis on la modie ensuite au a e fr et ` mesure quon reoit de linformation : u a c
> > > > > > > > > > # ## Liste de nom data <- data . frame ( nom = c ( " Ren e " ," Marcel " ," Raymonde " ," Isidore " )) e # ## Initialisation avec la valeur 0 data $ age <- 0 # ## Renseignement des lignes " au fur et ` mesure " a data $ age [1] <- 43 data $ age [3] <- 56 data $ age [4] <- 51 # ## Calcul de la moyenne mean ( data $ age )

[1] 37.5

13

Bien videmment, le calcul de la moyenne est faux puisque lge de Marcel na pas t e a ee renseign. La non-initialisation de la variable age (ou plus exactement son initialisation e a ` NA) aurait permis dviter lerreur : e
> > > > > > > > > > # ## Liste de nom data <- data . frame ( nom = c ( " Ren e " ," Marcel " ," Raymonde " ," Isidore " )) e # ## Initialisation avec la valeur NA data $ age <- NA # ## Renseignement des lignes data $ age [1] <- 43 data $ age [3] <- 56 data $ age [4] <- 51 # ## Calcul de la moyenne mean ( data $ age )

[1] NA

- D2 Dans lappel dune fonction, spciez les arguments par leur nom. e Ne pas respecter cette r`gle, cest sexposer ` intervertir involontairement lordre des e a arguments :
> > + + > > > > > # ## D finition de la fonction IMC e IMC <- function ( taille , poids ){ return ( poids / taille ^2) } # ## Mes param` tres e monPoids <- 86 maTaille <- 1.80 # ## Mon IMC sans specifier le nom des arguments IMC ( monPoids , maTaille )

[1] 0.0002433748 > # ## Mon IMC en specifiant le nom des arguments > IMC ( poids = monPoids , taille = maTaille ) [1] 26.54321

- D3 Nutilisez jamais de variable globale. Jamais. Une variable globale est une variable qui est dnie ` lextrieur dune fonction. D`s e a e e lors, lutilisation de la fonction dpend dautre chose que delle-mme. e e Or, le principe prludant ` la construction dune fonction est le mme que celui dune e a e mthode : elle doit tre automome, ne pas avoir besoin de lenvironnement global. Une e e fois termin, le programmeur ne doit plus avoir besoin de lire son code. Une fonction doit e 14

pouvoir fonctionner mme si son environnement change. En particulier, si vous copiere coller votre fonction dans un autre programme, elle doit fonctionner sans amnagement. e Dans lexemple suivant, la fonction dnie nest utilisable que pour moi et non pour e lui :
> > > > > > > > + + + > > # ## Variables mesAnneesDEtude <- 8 monSalaire <- 2500 sesAnneesDEtude <- 5 sonSalaire <- 3300 # ## Variation sur salaire # ## la variable mesAnneesDEtude est globale salaireDetail <- function ( salaire ){ cat ( " Salaire horaire = " , salaire / 35) cat ( " \ nRentabilit des tudes = " , salaire / mesAnneesDEtude ) e e } # ## Pour moi salaireDetail ( salaire = monSalaire )

Salaire horaire = 71.42857 Rentabilit des tudes = 312.5 e e > # ## Pour lui > salaireDetail ( salaire = sonSalaire ) Salaire horaire = 94.28571 Rentabilit des tudes = 412.5 e e

Aucune erreur nest signale. Et pourtant, le calcul de Rentabilite pour lui est e faux...
> > > > > > > > + + + > > # ## Variables mesAnneesDEtude <- 8 monSalaire <- 2500 sesAnneesDEtude <- 5 sonSalaire <- 3300 # ## Variation sur salaire # ## la variable mesAnneesDEtude est globale salaireDetail <- function ( salaire , anneesDEtude ){ cat ( " Salaire horaire = " , salaire / 35) cat ( " \ nRentabilit des tudes = " , salaire / anneesDEtude ) e e } # ## Pour moi salaireDetail ( salaire = monSalaire , anneesDEtude = mesAnneesDEtude )

Salaire horaire = 71.42857 Rentabilit des tudes = 312.5 e e > # ## Pour lui > salaireDetail ( salaire = sonSalaire , anneesDEtude = sesAnneesDEtude ) Salaire horaire = 94.28571 Rentabilit des tudes = 660 e e

15

- D4 Nutilisez pas dabrviation. e Par exemple, utilisez FALSE / TRUE et non 0 / 1 ou F / T. Les abrviations diminuent e la lisibilit du code. e Enn, tout r`glement qui se respecte devrait comporter une clause prcisant de ne e e pas trop respecter le r`glement (sinon, gare au fanatisme...) e - D5 La clarte doit primer sur le respect des r`gles. e e Si dans un cas particulier, une r`gle nuit ` la lisibilit, ignorez-la ! e a e Par exemple, plusieurs instructions if successives peuvent tre plus lisibles si on les e note sur une ligne unique. En respectant les r`gles : e
setReplaceMethod( " [ " ," ClusterizLongData " , function (x ,i ,j , value ){ i f ( i == " id " ){ x@id <- value } else { } i f ( i == " var " ){ x@var <- value } else { } i f ( i == " name " ){ x@name <- value } else { } } )

Le code plus lisible quand on applique la r`gle D5 : e

setReplaceMethod( " [ " ," ClusterizLongData " , function (x ,i ,j , value ){ i f ( i == " id " ){ x@id <- value } e l s e {}; i f ( i == " var " ){ x@var <- value } e l s e {}; i f ( i == " name " ){ x@name <- value } e l s e {}; } )

Astuces de programmation

Enn, voil` quelques astuces de programmation. Ce ne sont pas ` prcisment parler a a e e des bonnes pratiques, elles rentrent plus dans la catgorie des mthodes de programmae e tion lies aux spcicits de R. e e e 16

1. Testez votre code. Testez votre code rguli`rement, ncrivez pas un long code pour e e e ne le tester qu` la n, cela rendrait le dbuggage tr`s dicile. a e e 2. Ecrivez de nombreuses petites fonctions et testez-les au fur et ` mesure. a 3. Nutilisez pas x[ind,], remplacez-le par x[ind,drop=FALSE]. 4. Nutilisez pas x==NA, remplacez-le par is.na(x). 5. Nutilisez pas 1:length(x), remplacez-le par seq(along=x). 6. Nattachez pas vos data.frame ` lenvironnement (cela les tranformerait en vaa riables globales, infraction D3). 7. Nutilisez pas = pour vos aectations, remplacez-le par <-. 8. Nessayez pas dcrire un code optimal. Ecrivez un code clair et simple. Plus tard, e quand votre code sera oprationnel, bien plus tard, il sera temps de penser ` e a loptimisation. 9. Les boucles ne sont pas ecaces dans R. Il est prfrable de les remplacer par les ee fonctions lapply et sapply. Concernant les tests rguliers, il est plus facile de tester une fonction quune mthode. e e Aussi, il est plus simple de dclarer la fonction utilise par une mthode ` part. On vrie e e e a e ensuite quelle fonctionne correctement puis on lint`gre dans la mthode. Enn, une fois e e la mthode dclare, la fonction peut tre supprime sans que cela naecte la mthode. e e e e e e A quoi bon la supprimer, diriez-vous ? Cest simplement pour ne pas laisser trainer dans lespace de travail des variables, fonctions ou objets qui ne seront plus utilises. e Cest un peu comme passer lponge sur la table apr`s le petit djeuner pour enlever les e e e miettes. De mani`re gnrale, plus cest propre, moins il y a de bugs... e e e 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 : e
> > + + + > > > > > > > # ## D finition de la fonction e . 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 e # ## - ... # ## Ensuite , d finition de la m thode e e

17

> + + + + > >

setMethod( f = " methodA " , signature = " clasA " , d e f i n i t i o n =. clasA . methodA ) # ## Puis n toyage e rm (. clasA . methodA )

Rfrences ee
[1] CIRAD. GuR : Groupe des Utilisateurs de R, 2004 http://forums.cirad.fr/logiciel-R. [2] M. Mchler. Good Programming Practice, 2004 a http://www.ci.tuwien.ac.at/Conferences/useR-2004/Keynotes/Maechler.pdf. [3] R-Core Team. Liste de diusion, mailto:r-help@r-project.org.

18