Conseils impératifs

Plus que de simples conseils, des règles à ne surtout pas transgresser (sauf quand c’est nécessaire).
Voir aussi la page sur comment commencer un travail.

Un travail, un dossier

[**R*] comme tout logiciel va s’ouvrir par défaut toujours dans le même répertoire. Erreur, c’est un coup à avoir des données dans tous les sens ou de commencer chaque session en effaçant tout . Un travail, un répertoire. Avec les données brutes (les tableaux en .csv par ex), les graphiques & autres sorties (dans des sous-dossiers c’est plus clair) & les fichiers de macro etc. spécifiques de ce travail. Comme ça on termine chaque session en enregistrant son travail et on reprend tranquillement le lendemain avec toutes ses données. [**RStudio*] gère ça très bien avec un "projet" par travail.

garder ses données ? La question peut paraître bizarre, on ne va pas effacer tout son travail tous les soirs ? Et bien si. Mais avec un chat dans la manche : vous avez bien entendu gardé trace de votre travail dans un notebook [**RMarkdown*], [**org.mode*] ou autre. Et le lendemain matin vous faites tourner ce fichier & vous repartez sur une base saine. La seule limite serait le très très gros travail, très long à tourner. Le plus simple est alors de jouer avec l’option cache = TRUE des chuncks qui garde en mémoire le résultat des calculs (tant qu’il n’y a pas de changement) au lieu de refaire le calcul à chaque fois.

Et pour les macros qui servent tout le temps ? Deux méthodes :

• Méthode brute : Un fichier [**script.R*] quelque part & qu’on appelle dans le [**.Rprofile*] pour le charger à chaque démarrage :
   source("/home/mondossier/scripts.R")
• Plus élégant, créer un package à usage perso ce qui est plus simple qu’on pourrait croire & surtout très bien expliqué chez thinkR

  Ne pas utiliser attach

  IL est vrai que c’est lourd de toujours devoir écrire [*monfichier$mavariable*]. Et un petit
   > attach(monfichier)
  est bien tentant. Mais plus tard vous allez créer un second data.frame ne concernant qu’une partie de votre échantillon par exemple avec les mêmes variables. Et là commencent les ennuis. Ou vous allez utiliser une routine qui y perdra ses petits. Donc, désolé, on n’attache pas un data.frame. Pour un travail simple avec un seul data.frame, n’hésitez pas, simplifiez-vous la vie ! Pour les fonctions un peu complexe à écrire il existe souvent une commande [*data*] qui permet de simplifier l’écriture. les deux écritures suivantes sont strictement équivalentes :

  1.  logis1 <- glm(fichier$sortie ~ fichier$age + fichier$sexe + fichier$pouls, family="binomial")
  2. logis1 <- glm(sortie~age + sexe + pouls, data=fichier, family="binomial")

  Télécharger

  Sauvegarder

  Oui je sais je me répète, je suis la proie des idées fixes. Mais un ordinateur n’est qu’un machin mécanique qui peu tomber en panne ou recevoir un verre de café... Donc on sauvegarde régulièrement, sur plusieurs supports. Je vous laisse le choix du logiciel, de la technique. Sur Mac, [**TimeMachine*] est remarquable, simple d’emploi, transparent. Pour ma part sous Linux j’utilise un script basé sur rsync. Voir plus haut, on ne sauvegarde que ses données & son notebook. Ça suffit. Avec [**RStudio*], n’oubliez pas de créer un projet. Toutes vos données y compris les fichiers spécifiques à [**R*] seront dedans ce qui simplifie la maintenance.

  Utiliser un gestionnaire de versions

  Dés que votre travail prend de l’amplitude, se complexifie, vous aurez parfois envie de tester des trucs ou, plus simplement de revenir à l’état du travail d’hier matin, avant que vous ne vous embourbiez dans ce (...censuré...) de régression de (...censuré...). Rien de plus simple avec un gestionnaire de version. Ça demande d’apprendre à s’en servir (rien de sorcier, ce n’est pas [**R*] !) et un peu de rigueur ensuite. Mais quel confort. Il en existe plusieurs (Subversion, Mercurial, Git...). Ne connaissant que [**Git*] j’aurai du mal à vous en conseiller un. Des tutos pour apprendre à les utiliser sur openclassroom : -* Pour git -* Pour Subversion