9
votes

R Code Exemples / Meilleures pratiques

Je suis nouveau à r et avoir eu du mal à assembler des informations de diverses sources en ligne liées à ce qui est considéré comme une "bonne" pratique avec l'écriture de code R. J'ai lu des guides de base, mais j'ai eu du mal à trouver des informations qui sont définitivement à jour.

  1. Quels sont quelques exemples de classes S3 bien écrites / documentées?
  2. Que diriez-vous des classes S4 correspondantes?
  3. Quelles conventions utilisez-vous lorsque vous commencez à commenter des classes / fonctions? Pouvez-vous mettre tous vos commentaires dans les fichiers .rd. La synchronisation de ces fichiers est-elle ennuyeuse?

0 commentaires

4 Réponses :


5
votes

C'est une demi-douzaine de questions ou plus groupées en une, ce qui rend difficile la réponse.

Essayons donc de l'intérieur: essayez d'abord de résoudre votre problème d'emballage Rodbc. Une représentation de code se suggérera. Je commencerais avec des fonctions simples, puis peut-être construire un paquet autour de lui. Qui vous donne déjà une encapsulation.

Une grande partie du reste est le style. Certains codes r bien éminents jurent par S4, tandis que d'autres raisons à ce sujet. Vous pouvez toujours lire les paquets d'autres personnes ainsi que le code dans RI lui-même. Et vous pouvez toujours ré-implémenter votre emballage Rodbc de différentes manières et la comparaison de vos propres approches.

Edit: vous reflet de votre mise à jour et une question beaucoup raccourcie: choisissez des paquets de Cran, en particulier parmi ceux que vous utilisez. Je pense que vous trouverez rapidement un peu plus ou moins intéressant selon votre style.


2 commentaires

Tu as très raison. J'ai enlevé la seconde moitié de ma question. Désolé pour ça et merci.


Je discuterais de modifier la question elle-même pour être plus ciblée: plutôt que "des exemples de code R / des meilleures pratiques" en font quelque chose comme "R: Quand utiliser des classes S3 ou S4?"; Ce serait beaucoup plus gérable.



5
votes

pour 3. Utilisez Roxygen - cela fonctionne comme Javadoc pour prendre des commentaires dans vos fichiers source et construire des fichiers RD.


1 commentaires

Merci Hadley, c'est exactement ce que je cherchais.



7
votes

OU UTILISER S3, S4 ou un paquet du tout est la plupart du temps un problème de style (comme le dit Dirk), mais je suggère d'utiliser l'un de ceux-ci si vous voulez avoir un objet très structuré (comme vous le feriez dans toute langue de l'oop). Par exemple, toutes les classes de la série chronologique ont des objets de série chronologique (je crois qu'ils sont tous S3 à l'exception de son ) car il leur permet d'appliquer certains comportements autour de la construction et de l'utilisation de ces objets. . De même avec la question à propos de la création d'un forfait: c'est une bonne idée de le faire si vous voulez réutiliser votre code fréquemment ou si le code sera utile à quelqu'un d'autre. Cela nécessite un peu plus d'effort, mais la structure organisationnelle ajoutée peut facilement compenser le coût.

Concernant S3 vs. S4 (discuté sur R-Aide Ici et ici ) , la ligne directrice de base est que les classes S3 sont plus "rapides et sales" tandis que les classes S4 placent plus contrôle rigide sur des objets et des types . Si vous travaillez sur le bioconducteur, vous utiliserez généralement S4 (voir, par exemple, "Classes et méthodes S4" ).

Je recommanderais de lire quelques-unes des éléments suivants:

  1. "A (pas tellement) Introduction courte à S4" de Christophe Genolini
  2. "Programmeurs 'niche: une classe simple, dans S3 et S4" Par Thomas Lumley
  3. "Brobdingnag: un paquet" Hello World '' utilisant des méthodes S4 "Par Robin Ks Hankin
  4. "Conversion des packages vers S4" par Douglas Bates < / li>
  5. "Comment fonctionne des méthodes S4" par John Chambers

    Pour la documentation, la suggestion de Hadley est sur place: Roxygen facilitera la vie et met la documentation juste à côté du code. Cela de côté, vous voudrez peut-être toujours fournir d'autres commentaires dans votre code au-delà de ce que Roxygen ou les fichiers d'homme exigent, auquel cas il est une bonne pratique de commenter votre code pour d'autres développeurs. Ces commentaires ne se retrouveront pas dans votre colis; ils ne seront visibles que dans le code source.


1 commentaires

Merci un bouquet, Shane. Cela confirme beaucoup ce que j'ai lu et que les liens au même endroit sont très utiles.



4
votes

Un peu plus de style associé à la substance, mais le Google R Guide de style vaut la peine de lire:


1 commentaires

Ça fait vraiment. Il semble être ici maintenant