Série de propositions très bien qu'on a trainé à valider pour une obs…

…cure raison (#460) * ajout de la fonction ```data.table::fcase``` (#456) * ajout de la fonction ```data.table::fcase``` ```data.table::fcase``` utilise une implémentation plus efficace que le chainage manuel et est particulièrement intuitive dans son utilisation * Update 03_Fiches_thematiques/Fiche_datatable.Rmd * Update 03_Fiches_thematiques/Fiche_datatable.Rmd * Update 03_Fiches_thematiques/Fiche_datatable.Rmd Co-authored-by: Lino Galiana <[email protected]> * Ajout mention de DuckDB (#452) * Proposition modification encadré (#444) * MAJ discours sur openxls vs read_excel pour les imports (#453) * Contenu du commit : - Suppression de la recommandation de privilégier openxlsx::read.xlsx par rapport à readxl::read_excel pour la lecture ; - Ajout d'un encadré `Remarque` qui cite le package openxlsx comme package à privilégier pour les exports. * correction orthographe * Petite MAJ partie sur readr (#451) * Contenu du commit : - Suppression de la remarque sur le fait de privilégier fread() plutôt que les fonctions de {readr} ; - Ajout de l'argument `col_select` pour `read_csv()` et `read_csv2()` ; - Modification des parties qui parlent de l'impossibilité de sélectionner des colonners avec {readr} ; - Ajout d'un paragaphe qui compare les performances d'import sur le fichier des prénoms de l'Insee (readr vs. data.table vs. arrow). * Contenu du commit : - Plus de read_csv() et read_csv2() - Nouveau benchmark avec lazy=TRUE pour read_delim() * Remplacement cheatsheet de readr * Update 03_Fiches_thematiques/Fiche_import_fichiers_plats.Rmd Co-authored-by: Lino Galiana <[email protected]> * Ajout de styler dans la boîte à outils des bonnes pratiques (#455) * Remplacement url RStudio->Posit * Ajout styler * Update 02_Bonnes_pratiques/06-outils.Rmd * Update 02_Bonnes_pratiques/06-outils.Rmd * Update 02_Bonnes_pratiques/06-outils.Rmd Co-authored-by: Lino Galiana <[email protected]> * gitignore close #258 Co-authored-by: Thomas Faria <[email protected]> Co-authored-by: Damien Dotta <[email protected]>
InseeFrLab · Jan 19, 2023 · 5a190a6 · 5a190a6
1 parent af635fb
commit 5a190a6
Show file tree

Hide file tree

Showing 8 changed files with 143 additions and 56 deletions.
diff --git a/02_Bonnes_pratiques/06-outils.Rmd b/02_Bonnes_pratiques/06-outils.Rmd
@@ -57,6 +57,31 @@ g
 #> ───────────────────────────────────────────────────────────────────────────
 ```
 
+## Le *package* `styler`
+
+Le package `styler` met en forme votre code selon le [guide de style `tidyverse`](https://style.tidyverse.org/). Il permet ainsi de conserver un style de codage cohérent d'un projet à l'autre et s'applique à une sélection de code, un fichier ou même à l'ensemble d'un projet.
+
+Par exemple, si je souhaite vérifier le style de mon fichier "inst/app/ui.R" :  
+
+```{r, eval = FALSE}
+style_file(path = "inst/app/ui.R")
+#> Styling  1  files:
+#>  inst/app/ui.R i 
+#> ----------------------------------------
+#> Status	Count	Legend 
+#> √ 	0	File unchanged.
+#> i 	1	File changed.
+#> x 	0	Styling threw an error.
+#> ----------------------------------------
+#> Please review the changes carefully!
+```
+
+Le fichier a été modifié et grâce à [`Git`](https://www.book.utilitr.org/git.html) on peut facilement parcourir tous les changements de style effectués par le package. Par exemple :  
+
+![Conséquence de `styler`](./pics/bonnespratiques/img_styler.png){width=100%}
+Enfin le package `styler`permet de définir votre propre guide de style et de formater du code en fonction de celui-ci. Pour en savoir plus, consultez [cette vignette](https://styler.r-lib.org/articles/customizing_styler.html)
+
+
 ## Les `addins` {#presentation_addin}
 
 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 :
@@ -101,5 +126,5 @@ conditional_output <- function(path){
 
 ## Cheatsheets
 
-On peut trouver des aides mémoires en ligne grâce aux [cheatsheets](https://www.rstudio.com/resources/cheatsheets/). Celle relative à ` RStudio` est disponible [ici](https://github.com/rstudio/cheatsheets/raw/master/rstudio-ide.pdf).
+On peut trouver des aides mémoires en ligne grâce aux [cheatsheets](https://posit.co/resources/cheatsheets/). Celle relative à ` RStudio` est disponible [ici](https://posit.co/wp-content/uploads/2022/10/rstudio-ide-1.pdf).
 
diff --git a/03_Fiches_thematiques/Fiche_connexion_bdd.Rmd b/03_Fiches_thematiques/Fiche_connexion_bdd.Rmd
@@ -32,7 +32,7 @@ Ainsi, une **requête** est une commande plus ou moins complexe permettant de ma
 * adresser une requête au serveur pour que ce dernier accomplisse les opérations directement sur la base de données, et éventuellement compléter la requête de manière à en récupérer le résultat (sous une forme éventuellement agrégée, selon l'usage qu'on souhaite *in fine* avoir de l'information ainsi transformée) ;
 * soit un mélange des deux, visant à tirer partie à la fois des performances de gestion de gros volumes du serveur, mais également des outils spécifiques (en particulier en matière de statistiques ou d'économétrie) offert par le client.
 
-Reste la question de l'interfaçage entre le client et le serveur, c'est-à-dire la façon dont les deux vont communiquer de façon intelligible, supposé être transparent pour l'utilisateur. Cet interfaçage est assuré par un *driver* du côté client, qui permet à celui-ci d'envoyer des requêtes que le serveur peut interpréter. Il est donc essentiel de s'assurer que ce *driver* existe du côté client et qu'il est utilisé par le logiciel. En effet, il existe un grand nombre de SGBD, dont les caractéristiques techniques varient, par exemple `MySQL`, `Oracle`, `Postgres`, `SQLite`, etc. C'est ici que le package `DBI` entre en jeu. Ce _package_ contient un certain nombre de fonctions génériques permettant de communiquer avec un serveur de base de données, quel que soit le type de base de données en question. Ce _package_ doit être utilisé avec un autre _package_ qui contient le *driver* correspondant au type de la base de données que l'on souhaite requêter. Dès lors que ce _driver_ existe et est correctement chargé, les fonctions de `DBI` permettent d'établir la connexion avec le serveur et de lancer des requêtes.
+Reste la question de l'interfaçage entre le client et le serveur, c'est-à-dire la façon dont les deux vont communiquer de façon intelligible, supposé être transparent pour l'utilisateur. Cet interfaçage est assuré par un *driver* du côté client, qui permet à celui-ci d'envoyer des requêtes que le serveur peut interpréter. Il est donc essentiel de s'assurer que ce *driver* existe du côté client et qu'il est utilisé par le logiciel. En effet, il existe un grand nombre de SGBD, dont les caractéristiques techniques varient, par exemple `MySQL`, `Oracle`, `Postgres`, `SQLite`, `DuckDB`, etc. C'est ici que le package `DBI` entre en jeu. Ce _package_ contient un certain nombre de fonctions génériques permettant de communiquer avec un serveur de base de données, quel que soit le type de base de données en question. Ce _package_ doit être utilisé avec un autre _package_ qui contient le *driver* correspondant au type de la base de données que l'on souhaite requêter. Dès lors que ce _driver_ existe et est correctement chargé, les fonctions de `DBI` permettent d'établir la connexion avec le serveur et de lancer des requêtes.
 
 ### Qu'est-ce que SQL ?
 
@@ -242,7 +242,7 @@ L'utilisation des fonctions `dbSendQuery` et `dbGetQuery` du *package* `DBI` per
 * indépendant de `R` : les requêtes SQL qui ont été élaborées en `R` pourront être aisément réutilisées dans un autre contexte (en `Python` par exemple) ;
 * puissance du langage : les requêtes écrites directement en SQL permettent d'utiliser toutes les fonctions de SQL pour le traitement des données par la base de données.
 
-Le principal inconvénient de `DBI` et du langage SQL est que les détails du langage SQL peuvent varier légèrement d'un type de base de données à l'autre (MySQL, SQLite, Postgres...), ce qui peut entraîner des confusions et des bugs (par exemple si on reprend un exemple trouvé sur internet).
+Le principal inconvénient de `DBI` et du langage SQL est que les détails du langage SQL peuvent varier légèrement d'un type de base de données à l'autre (MySQL, SQLite, Postgres, DuckDB...), ce qui peut entraîner des confusions et des bugs (par exemple si on reprend un exemple trouvé sur internet).
 
 Le *package* `dbplyr` a pour avantage de proposer une syntaxe simple, très proche de `dplyr`, ce qui réduit le coût d'apprentissage. Par ailleurs ce _package_ couvre l'essentiel des besoins standards en matière de base de données. Il a toutefois deux inconvénients : ce *package* ralentit l'apprentissage de SQL par l'utilisateur et empêche de réaliser des requêtes complexes réservées aux agents maîtrisant SQL. Par ailleurs, la syntaxe de `dbplyr` est spécifique à `R` et à l'écosystème `tidyverse`, créant ainsi une dépendance au langage.
 

diff --git a/03_Fiches_thematiques/Fiche_datatable.Rmd b/03_Fiches_thematiques/Fiche_datatable.Rmd
@@ -592,13 +592,21 @@ bpe_ens_2018 %>%
   )
 ```
 
-et le code équivalent en `data.table`, nécessitant beaucoup moins de mémoire vive :
+Deux alternatives existent en `data.table` nécessitant toutes deux beaucoup moins de mémoire vive :
 
 ```{r}
 bpe_ens_2018_dt[ , NB_EQUIP_HORS_CHAUSS := NB_EQUIP
                  ][TYPEQU == "B304", NB_EQUIP_HORS_CHAUSS := NA_real_]
 ```
 
+ou bien en utilisant la fonction `data.table::fcase` dont le fonctionnement ressemble à celui de `dplyr::case_when`  :
+
+```{r}
+bpe_ens_2018_dt[ , NB_EQUIP_HORS_CHAUSS := data.table::fcase(TYPEQU == "B304", NA_real_,
+                                                   TYPEQU != "B304", NB_EQUIP)
+                                                   ]
+```
+
 ### Attention en utilisant `:=`
 
 L'utilisation de la fonction `:=` est déroutante lorsqu'on découvre `data.table`. Voici trois remarques qui vous feront gagner du temps :

diff --git a/03_Fiches_thematiques/Fiche_gerer_dependances.Rmd b/03_Fiches_thematiques/Fiche_gerer_dependances.Rmd
@@ -395,7 +395,7 @@ projet. On peut choisir d'utiliser cette méthode à n'importe quel moment de la
 réalisation du projet.
 
 ::: specificite 
-La méthode reposant sur le package `{renv}` ne fonctionne pas dans l'espace informatique AUS.
+Dans l'espace informatique AUS, les commandes courantes issues du package `{renv}` fonctionnent. Cependant quelques soucis ont été constatés lors d'utilisations plus spécifiques et avancées du package.
 :::
 
 Pour commencer à utiliser `{renv}`, il suffit d'exécuter :

diff --git a/03_Fiches_thematiques/Fiche_git_utilisation.Rmd b/03_Fiches_thematiques/Fiche_git_utilisation.Rmd
@@ -235,15 +235,19 @@ A ce stade, `Git` est maintenant capable de contrôler les versions des fichiers
 - le fichier `.Renviron` (voir la fiche [Personnaliser la configuration de `R`]) ;
 - les codes contenant des informations confidentielles (comme les mots de passe, les _tokens_ ou les clés d'API).
 
-**Les fichiers exclus du suivi des modifications sont répertoriés dans un fichier nommé `.gitignore`.** Si le projet a été créé selon l'une des deux méthodes décrites précédemment, `RStudio` a créé automatiquement un fichier `.gitignore` dans le dossier du projet, et ce fichier contient par défaut les lignes suivantes :
+**Les fichiers exclus du suivi des modifications sont répertoriés dans un fichier nommé `.gitignore`.**
+Si le projet a été créé selon l'une des deux méthodes décrites précédemment,
+`RStudio` a créé automatiquement un fichier `.gitignore` dans le dossier du projet, et ce fichier contient par défaut les lignes suivantes :
 
 ~~~r
 .Rhistory
 .RData
 .Rproj.user
 ~~~
 
-**Il est souvent nécessaire d'ajouter des lignes au fichier `.gitignore` pour exclure certains fichiers du suivi des modifications.** Pour éditer le fichier, il suffit d'exécuter la commande `usethis::edit_git_ignore(scope = "project")`. Par exemple, vous pouvez ajouter les lignes suivantes pour exclure tous les fichiers de format csv, SAS et Excel du suivi des modifications :
+**Il est souvent nécessaire d'ajouter des lignes au fichier `.gitignore` pour exclure certains fichiers du suivi des modifications.**
+Pour éditer le fichier, il suffit d'exécuter la commande `usethis::edit_git_ignore(scope = "project")`.
+Par exemple, vous pouvez ajouter les lignes suivantes pour exclure tous les fichiers de format csv, SAS et Excel du suivi des modifications :
 
 ~~~r
 *.csv
@@ -252,7 +256,8 @@ A ce stade, `Git` est maintenant capable de contrôler les versions des fichiers
 *.xlsx
 ~~~
 
-Il est également conseillé d'exclure les fichiers pouvant être produits par des documents `R Markdown` (notamment les fichiers pdf et html). Par exemple, pour exclure tous les fichiers de formats `PDF` et `HTML`, les lignes suivantes suffisent :
+Il est également conseillé d'exclure les fichiers pouvant être produits par des documents `R Markdown`
+(notamment les fichiers pdf et html). Par exemple, pour exclure tous les fichiers de formats `PDF` et `HTML`, les lignes suivantes suffisent :
 
 ~~~r
 *.html
@@ -273,7 +278,9 @@ utilitr::include_image("./pics/git/onglet_git12.png", compression = FALSE)
 
 
 ::: {.remarque}
-Le site [https://www.toptal.com/developers/gitignore](gitignore.io) fournit un certain nombre de modèles de fichiers `.gitignore` selon le type de projet associés à `Git`. 
+Le site [https://www.toptal.com/developers/gitignore](gitignore.io) fournit un certain nombre de modèles de fichiers `.gitignore` selon le type de projet
+associés à `Git`. Vous pouvez également utiliser [ce modèle](https://github.com/github/gitignore/blob/main/R.gitignore) pour constituer une 
+base de départ.
 :::
 
 ## Suivre les modifications d'un projet RStudio avec `Git` {#git-local}