Chapitre 5 Boite à outils
Des packages ou addins Rstudio ont été développés pour évaluer la qualité de la syntaxe de codes intégrés dans un projet. Les packages styler
et goodpractice
évaluent la qualité d’un code suivant quelques règles simples. En développement de package, on pourra utiliser la fonction devtools::check()
qui effectue environ 80 tests pour assurer la robustesse du code. Les problèmes potentiels sont alors signalés selon leur caractère critique: les erreurs
et warnings
sont des problèmes de robustesse préoccupants, les notes
sont des problèmes secondaires pouvant affecter la robustesse du code.
5.1 Le package goodpractice
Supposons qu’on ait un package dont on souhaite assurer la diffusion. Le package goodpractice
permet de lister les écarts à quelques règles de bonnes pratiques. Voici un exemple de sortie goodpractice
:
g <- goodpractice::gp(mypackage)
g
#> ── GP badpackage ──────────────────────────────────────────────────────────
#>
#> It is good practice to
#>
#> ✖ not use "Depends" in DESCRIPTION, as it can cause name
#> clashes, and poor interaction with other packages. Use
#> "Imports" instead.
#> ✖ omit "Date" in DESCRIPTION. It is not required and it gets
#> invalid quite often. A build date will be added to the package
#> when you perform `R CMD build` on it.
#> ✖ add a "URL" field to DESCRIPTION. It helps users find
#> information about your *package* online. If your *package* does
#> not have a homepage, add an URL to GitHub, or the CRAN package
#> *package* page.
#> ✖ add a "BugReports" field to DESCRIPTION, and point it to a bug
#> tracker. Many online code hosting services provide bug
#> trackers for free, https://github.com, https://gitlab.com,
#> etc.
#> ✖ omit trailing semicolons from code lines. They are not needed
#> and most R coding standards forbid them
#>
#> R/semicolons.R:4:30
#> R/semicolons.R:5:29
#> R/semicolons.R:9:38
#>
#> ✖ not import *packages* as a whole, as this can cause name clashes
#> between the imported packages. Instead, import only the
#> specific functions you need.
#> ✖ fix this R CMD check ERROR: VignetteBuilder *package* not
#> declared: ‘knitr’ See section ‘The DESCRIPTION file’ in the
#> ‘Writing R Extensions’ manual.
#> ✖ avoid 'T' and 'F', as they are just variables which are set to
#> the logicals 'TRUE' and 'FALSE' by default, but are not
#> reserved words and hence can be overwritten by the user.
#> Hence, one should always use 'TRUE' and 'FALSE' for the
#> logicals.
#>
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> R/tf.R:NA:NA
#> ... and 4 more lines
#>
#> ───────────────────────────────────────────────────────────────────────────
5.2 Les addins
Les addins
Rstudio sont des fonctionnalités supplémentaires à Rstudio développées de manière collaborative. C’est l’équivalent des plugins des moteurs de recherche. Les addins
sont des outils pratiques pour gagner du temps dans l’édition du code:
- Installation simple grâce au package
addinslist``:
install.packages(‘addinslist’)`; - Ceux sur
CRAN
sont disponibles pour tous, ceux surgithub
nécessitent d’avoir configuré le proxy; - Génèrent automatiquement du code ou du texte utile pour les markdown.
Les addins sont disponibles en haut de l’éditeur:
Avec le package addinslist
, on peut installer des addins à partir d’une fenêtre graphique:
5.3 Quelques addins utiles
-
snippetsaddins
: convertir slash automatiquement pour avoir des chemins valides; - “monchemin/toto/fichier.csv” -> “monchemin\toto\fichier.csv”
-
ggedit
: aide pour générer un code pour graphiquesggplot2
; -
JADD
: en sélectionnant une fonction, on assigne les paramètres par défaut dans l’environnement; -
questionr
: recodage facilité des variablesfactor
; -
trackmd
: un outil de track change pourmarkdown
.
5.4 Cheatsheets
On peut trouver des aides mémoires en ligne grâce aux cheatsheets. Celle relative à Rstudio
est disponible ici.