Il primo codice sorgente dei pacchetti R da studiare in preparazione per la scrittura del proprio pacchetto

Sto programmando di iniziare a scrivere pacchetti R.

Ho pensato che sarebbe stato utile studiare il codice sorgente dei pacchetti esistenti per apprendere le convenzioni sulla costruzione dei pacchetti.

I miei criteri per i buoni pacchetti da studiare:

• Semplici idee statistiche / tecniche : il punto è conoscere la meccanica della costruzione del pacchetto. La comprensione del pacchetto non dovrebbe richiedere una conoscenza dettagliata altamente specifica del dominio sull'argomento effettivo del pacchetto.
• Stile di codifica semplice e convenzionale : sto cercando qualcosa di più Hello Worldma non molto di più. Trucchi e hack idiosincratici potrebbero distrarre quando apprendono i pacchetti R per la prima volta.
• Buon stile di codifica : il codice è ben scritto. Rivela sia una comprensione del buon codice, in generale, sia una consapevolezza delle convenzioni del codice in R.

Domande:

• Quali pacchetti sarebbe bene studiare?
• Perché il codice sorgente del pacchetto suggerito sarebbe buono da studiare relativamente ai criteri sopra menzionati o ad altri criteri che potrebbero essere rilevanti?

Aggiornamento (13/12/2010) Dopo i commenti di Dirk volevo chiarire che senza dubbio molti pacchetti sarebbero stati utili per studiare prima. Sono anche d'accordo che i pacchetti forniranno modelli per cose diverse (ad es. Vignette, classi S3, classi S4, unit test, Roxygen, ecc.). Tuttavia, sarebbe interessante leggere suggerimenti concreti sui buoni pacchetti per cominciare e sui motivi per cui sarebbero buoni pacchetti per cominciare.

Ho anche aggiornato la domanda sopra per fare riferimento a "pacchetti" anziché "pacchetto".

Suggerirei di guardare il pacchetto zoo per i seguenti motivi:

1. Ha diverse vignette ben scritte;
2. Esso utilizza uno spazio dei nomi utilizzando useDynLib, import, export, e S3method;
3. Ha diversi test unitari usando RUnit;
4. Fornisce buoni esempi di come creare / documentare metodi S3;
5. Ha alcune chiamate al codice C tramite l' .Callinterfaccia;
6. Contiene una demo (di stampa);
7. Mira a essere coerente con l'installazione del core R (ad es. Le funzioni si comportano in modo simile, non maschera / ignora le funzioni di base, ecc.)

Non usa roxygen, il che è molto utile, ma 7 su 8 non sono male. ;-)

Per rispondere ai tuoi criteri:

1. Il concetto è semplice: zooè una classe simile a una matrice ordinata da qualcosa . Nessuna conoscenza specifica del dominio necessaria.
2. zoo sembra avere alcune convenzioni di codifica idiosincratiche, ma niente di esagerato che impedisce la comprensione del codice.
3. zoo mira ad essere il più coerente possibile con R.

Non mi considero uno sviluppatore di pacchetti R affermato, ma recentemente ho subito il processo di scrittura e gestione di un pacchetto per il mio ambiente di lavoro.

In precedenza avevo scritto / mantenuto / aggiornato un set di script che avrei passato da un progetto all'altro tramite la source()funzione. Il risultato finale è stato che avrei finito con script per lo più ridondanti appesi in vari punti delle nostre unità di rete. Non è mai stato chiaro dove si trovasse la serie di script più aggiornata. Da allora sono migrato a scrivere / mantenere un pacchetto usando roxygen. Ha semplificato drasticamente la mia vita e reso più semplice condividere il mio lavoro con i colleghi.

Sulla base dei tuoi criteri di cui sopra, secondo la raccomandazione di rivedere i pacchetti che Hadley ha scritto. In particolare, penso che leggere attraverso il wiki di devtools sarebbe molto utile. Il codice di Hadley è ben documentato e molti dei suoi pacchetti utilizzano roxygen. Penso che scrivere e conservare un documento sia per le funzioni R sia per la documentazione R sia molto più semplice che disporli in due posizioni (file .R e .RD).

I pacchetti di Hadley servono anche alcuni concetti abbastanza elementari e sono relativamente facili da analizzare (imho) se stai cercando suggerimenti sulle idee degli aspetti tecnici. Mi ritrovo a scavare nel codice sorgente plyr quando cerco un puntatore sulla documentazione roxygen o altri compiti fondamentali.

Perché non adottare un approccio di campionamento casuale guidato empiricamente? Basta sceglierne alcuni e vedere quale lavoro fa per te.

Scherzi a parte, basta guardare alcuni pacchetti che tu stesso usi e che conosci. Scaricarli è semplice o, se preferisci, puoi anche visualizzarli tramite un'interfaccia web su R-Forge, RForge o Github.

Molto probabilmente finirai con pacchetti diversi per idee diverse. Alcuni potrebbero aiutarti nel modo in cui integrano, diciamo, una vignetta. Alcuni potrebbero aiutare con il codice compilato. O test unitari. O Roxygen. Ce ne sono circa 2600, quindi perché ossessionarsi per un singolo migliore?

Un altro consiglio potrebbe essere quello di esaminare i pacchetti su cui dipenderà o interagiranno i tuoi, specialmente se questi implementano alcuni elementi menzionati da Joshua Ulrich o sono stati scritti da autori famosi. Potrebbe essere utile imparare come vengono fatte le cose nel tuo campo, per garantire una certa compatibilità. Spesso le persone avranno pensato a determinati problemi e leggere la loro soluzione potrebbe essere utile.

consiglierei il pacchetto di risagoma di Hadley. puoi trovare la fonte su https://github.com/hadley/reshape