Comment à organiser de grands programmes de R?

Question

Lorsque j'entreprends un projet R de toute la complexité, mes scripts d'obtenir rapidement de long et confus.

Quelles sont certaines des pratiques que je peux adopter, de sorte que mon code sera toujours un plaisir de travailler avec? Je suis en train de penser à des choses comme

• Le Placement des fonctions dans les fichiers source
• Lors de casser quelque chose à un autre fichier source
• Ce qui devrait être dans le fichier principal
• L'utilisation de fonctions comme les unités d'organisation (si cela en vaut la peine étant donné que R rend difficile l'accès de l'état global)
• L'Indentation / saut de ligne pratiques.
  • Traiter ( comme {?
  • Mettre des choses comme )} sur 1 ou 2 lignes?

En gros, quelles sont vos règles de base pour l'organisation des grands R scripts?

Answer 1

La réponse standard est d'utiliser les paquets -- voir l' Écriture d'Extensions de R manuel ainsi que les différents tutoriels sur le web.

Il vous donne

• un quasi-automatique pour organiser votre code par thème
• vous encourage vivement à écrire un fichier d'aide, vous faire penser à propos de l'interface
• beaucoup de vérifications par R CMD check
• une chance d'ajouter des tests de régression
• ainsi que d'un moyen pour les espaces de noms.

Juste en cours d'exécution source() sur le code fonctionne pour de très courts extraits. Tout le reste doit être dans un paquet, même si vous ne prévoyez pas de le publier en tant que vous pouvez écrire les paquets internes pour les internes de dépôts.

Comme pour le " comment faire pour modifier une partie, la R Internes manuel a une excellente R des normes de codage dans la Section 6. Sinon, j'ai tendance à utiliser par défaut dans Emacs et ESS mode.

Mise à jour 2008-Aug-13: David Smith vient de blogué sur le Google R Guide de Style.

Answer 2

J'aime mettre des fonctionnalités différentes dans leurs propres fichiers.

Mais je n'aime pas la R du système de paquetages. C'est plutôt difficile à utiliser.

Je préfère une alternative légère, à la place d'un fichier des fonctions à l'intérieur d'un environnement (ce que tout autre langage appelle un "espace de noms") et de la joindre. Par exemple, j'ai fait un 'util' groupe de fonctions comme:

util = new.env()

util$bgrep = function [...]

util$timeit = function [...]

while("util" %in% search())
  detach("util")
attach(util)

Tout cela dans un fichier util.R. Lorsque vous source, vous obtenez l'environnement 'util' de sorte que vous pouvez appeler util$bgrep() ; mais en outre, l' attach() appel qui le rend si seulement bgrep() et un tel travail directement. Si vous n'avez pas mis l'ensemble de ces fonctions dans leur propre environnement, ils me polluent l'interprète de haut niveau de l'espace de noms (celui qui ls() montre).

J'ai essayé de simuler Python du système, où chaque fichier est un module. Ce serait mieux de l'avoir, mais cela semble OK.

Answer 3

Cela peut sembler un peu évident, surtout si vous êtes un programmeur, mais voici comment je pense que sur la logique et physique des unités de code.

Je ne sais pas si c'est votre cas, mais quand je travaille dans R, j'ai rarement commencer avec un grand complexe de programme à l'esprit. J'ai l'habitude de commencer dans un script et séparer le code en logiquement séparables unités, souvent à l'aide de fonctions. La manipulation des données et la visualisation du code placé dans leurs propres fonctions, etc. Et ces fonctions sont regroupées dans une section du fichier (manipulation de données dans le haut, puis la visualisation, etc). En fin de compte, vous voulez penser à la façon de rendre plus facile pour vous de maintenir votre script et de la baisse des taux de défaut.

Comment fine/coarse grains-vous faire de vos fonctions varient et il ya plusieurs règles de base: par exemple, 15 lignes de code, ou d'une "fonction devrait être responsable pour l'accomplissement de la tâche qui est identifié par son nom", etc. Votre kilométrage peut varier. Puisque R n'est pas en charge l'appel par référence, je suis généralement varier de faire mes fonctions trop fine quand elle consiste à faire passer les trames de données ou de structures similaires, autour de. Mais cela peut être une surcompensation pour certains idiot de la performance des erreurs quand j'ai commencé à R.

Quand à extraire des unités logiques dans leurs propres unités physiques (comme les fichiers source et le plus grand des groupements comme les paquets)? J'ai deux cas. Tout d'abord, si le fichier est trop grand et à faire défiler parmi logiquement indépendantes des unités, c'est une gêne. Deuxièmement, si j'ai des fonctions qui peuvent être réutilisés par d'autres programmes. J'ai l'habitude de commencer par placer quelques regroupés unité, disons fonctions de manipulation de données, dans un fichier séparé. Je peux alors source de ce fichier à partir de n'importe quel autre script.

Si vous allez déployer vos fonctions, alors vous devez commencer à réfléchir sur les paquets. Je n'ai pas déployer R code dans la production ou à des fins de réutilisation par d'autres, pour diverses raisons (brièvement: org culture préfère d'autres langues, des préoccupations au sujet de la performance, GPL, etc). Aussi, j'ai tendance à constamment raffiner et de l'ajouter à mes collections de la source des fichiers, et je préfère ne pas traiter les paquets quand je fais un changement. Donc, vous devriez vérifier le paquet d'autres réponses, comme Dirk, pour plus de détails sur ce front.

Enfin, je pense que votre question n'est pas forcément particulier pour R. je voudrais vraiment vous recommandons la lecture du Code par Steve McConnell qui contient beaucoup de sagesse à propos de ces problèmes et les pratiques de codage.

Answer 4

Je suis d'accord avec Dirk conseils!!! À mon humble avis, l'organisation de vos programmes à partir de scripts simples pour documenté paquets est, pour la Programmation en R, comme le passage du Mot à la TeX/LaTeX pour l'écriture. Je recommande de prendre un coup d'oeil à la très utile la Création de Packages R: Un Tutoriel par Friedrich Leisch.

Answer 5

Ma réponse concise:

1. Écrivez vos fonctions avec soin, d'identifier assez générale les entrées et les sorties;
2. Limiter l'utilisation de variables globales;
3. Utiliser les objets S3 et, le cas échéant, S4 objets;
4. Mettre les fonctions dans les paquets, en particulier lorsque vos fonctions sont l'appel de C/Fortran.

Je crois que R est de plus en plus utilisé dans la production, et donc la nécessité d'un code réutilisable est plus grand qu'avant. Je trouve l'interprète beaucoup plus solide qu'avant. Il ne fait aucun doute que la R est 100 à 300 fois plus lent que le C, mais le plus souvent le goulot d'étranglement est concentrée autour de quelques lignes de code, qui peut être déléguée à C/C++. Je pense que ce serait une erreur de déléguer les forces de R dans la manipulation des données et l'analyse statistique d'une autre langue. Dans ces cas, la perte de performance est faible, et en tout cas bien la peine de l'épargne dans l'effort de développement. Si le temps d'exécution étaient seuls en la matière, nous serions tous écrit en assembleur.