1.1 Noms des fichiers

Extensions Il existe plusieurs types de fichiers en R, chacun avec son extension:

• l’extension est .R pour les scripts;
• l’extension est .RData pour les fichiers de données (attention à la casse dans ce cas);
• Il est également possible d’enregistrer un objet R dans un format .rds;
• Les fichiers Rmarkdown sont enregistrés sous l’extension .Rmd.

Versions

• L’utilisation d’outils de contrôle de version tel que git est recommandée et est très bien intégrée dans Rstudio. L’intérêt de git est de permettre un suivi des évolutions du fichier bloc par bloc et contributeur par contributeur. Dans ce cas, il n’est pas nécessaire de millésimer les fichiers, l’historique des modifications d’un fichier étant géré par git (cf. Section Contrôle de version). Pour le versioning, on pourra également utiliser le Gitlab interne de la Drees ou de l’Insee.
• En l’absence de système de contrôle de version (git ou SVN), il est recommandé de millésimer les fichiers (scripts et données). Pour les données, on millésimera systématiquement avec la date (pour les agents de la Drees, la fonction rdrees::exporter_data propose de le faire automatiquement).

Organisation

• Pour les scripts, il est préférable d’indiquer en préfixe le numéro du script dans la série de scripts à exécuter (si cela s’applique) et en suffixe le millésimage. On peut ajouter le suffixe “_dev” pour les scripts en développement, et le suffixe “_prod” pour les scripts utilisés en production (à ne pas modifier). Ainsi, si un script est nommé 1_import_donnees_vdev_20190417.R, 1 indique le numéro du script (c’est le premier à exécuter dans le projet), vdev indique qu’il s’agit d’une version de développement et 20190417 indique le millésime.
• Pour millésimer automatiquement les fichiers de données en sortie d’un script, on peut utiliser le modèle de script suivant:

# parametres ---------------------------------------------
date <- Sys.Date()
chemin_donnees <- "I:/.../"
# code 
#...

# enregistrement -----------------------------------------
save(fichier, file = paste0(chemin_donnees, "fichier_", date, ".RData"))

On pourra sauvegarder des objets intermédiaires au cours du script. Pour s’assurer de la reproductibilité des scripts, l’intégralité du code devra être réexécuté in fine.

Bonnes pratiques:

• Ne pas utiliser de symboles spéciaux dans le nom du fichier (-.,;:\/$^`, caractères accentués, etc.);
• Privilégier les underscore (par exemple donnees_menages) au CamelCase (consiste à donner un nom en mettant une majuscule à chaque début de mot : par exemple donneesMenages). Si vous préférez le CamelCase, utilisez-le systématiquement dans tout le script pour uniformiser le code.

1.2 Noms des variables

Nom de la variable Il est recommandé d’utiliser des substantifs pour nommer une variable. Privilégier les underscores (par exemple donnees_menages) au CamelCase (par exemple donneesMenages). Si vous préférez le CamelCase, utilisez-le systématiquement dans tout le script pour uniformiser le code.

Bonnes pratiques

• Ne pas utiliser T ou F pour nommer des variables (car en plus d’être rarement des noms explicites ce sont les abréviations des booléens TRUE et FALSE);
• Ne pas utiliser de noms qui sont déjà des fonctions de base R (mean par exemple). Cela ne génère pas toujours d’erreur mais cela évite des erreurs difficilement détectables! Voici un exemple d’erreur difficile à détecter:

# On commence avec équivalence TRUE et T
TRUE == T

## [1] TRUE

2 == TRUE

## [1] FALSE

# On crée une variable T à un moment (shortcut de TRUE)
T <- 2

# On a rompu l'équivalence entre T et TRUE
TRUE == T

## [1] FALSE

2 == T

## [1] TRUE

1.3 Noms des fonctions

Nom de la fonction Il est recommandé d’utiliser des verbes pour nommer une fonction. Il est préférable de nommer une fonction en fonction de ce qu’elle fait. Privilégier les underscores (par exemple calculer_taxes) au CamelCase (par exemple calculerTaxes). Si vous préférez le camelCase, utilisez-le systématiquement dans tout le script pour uniformiser le code.

Nom des arguments Il est préférable de nommer les arguments explicitement dans un appel de fonction, sauf dans les cas où il ne peut y avoir d’équivoque. Exemple: calculer_taxes(revenu = 10000, taux = 0.2) plutôt que calculer_taxes(10000, 0.2). Si on choisit de ne pas nommer les arguments dans un appel de fonction, il faut alors respecter l’ordre des arguments.

Voici un exemple avec la fonction base::gsub(), dont les arguments sont pattern = ..., replacement = ..., x = ... dans cet ordre. Supposons qu’on appelle cette fonction mais qu’on se trompe dans l’ordre des arguments. Alors on ne remplacera pas toto par cool comme voulu mais aura un comportement difficile à anticiper:

my_awesome_func <- 
  function(x = "super toto", replacement = "cool", pattern = "toto"){
    gsub(x, replacement, pattern)
  }
my_awesome_func()

## [1] "toto"

my_awesome_func2 <- 
  function(x = "super toto", replacement = "cool", pattern = "toto"){
    gsub(x = x, replacement = replacement, pattern = pattern)
  }
my_awesome_func2()

## [1] "super cool"

Bonnes pratiques Comme pour le choix du nom des variables, il est recommandé de ne pas utiliser T ou F pour nommer des fonctions (car ce sont les booléens TRUE et FALSE) ou des noms qui sont déjà des fonctions de base R (mean par exemple).