Primer código fuente de paquetes R para estudiar en preparación para escribir su propio paquete

Estoy planeando comenzar a escribir paquetes R.

Pensé que sería bueno estudiar el código fuente de los paquetes existentes para aprender las convenciones de la construcción de paquetes.

Mi criterio para buenos paquetes para estudiar:

• Ideas estadísticas / técnicas simples : el punto es aprender sobre la mecánica de la construcción de paquetes. Comprender el paquete no debería requerir un conocimiento detallado altamente específico del dominio sobre el tema real del paquete.
• Estilo de codificación simple y convencional : estoy buscando algo un poco más Hello Worldpero no mucho más. Los trucos y trucos idiosincráticos distraerían la primera vez que se aprendan paquetes R.
• Buen estilo de codificación : el código está bien escrito. Revela tanto una comprensión de la buena codificación, en general, como una conciencia de las convenciones de codificación en R.

Preguntas:

• ¿Qué paquetes serían buenos para estudiar?
• ¿Por qué sería bueno estudiar el código fuente del paquete sugerido en relación con los criterios mencionados anteriormente o cualquier otro criterio que pueda ser relevante?

Actualización (13/12/2010) Después de los comentarios de Dirk, quería dejar en claro que, sin duda, muchos paquetes serían buenos para estudiar primero. También estoy de acuerdo en que los paquetes proporcionarán modelos para diferentes cosas (por ejemplo, viñetas, clases S3, clases S4, pruebas unitarias, Roxygen, etc.). Sin embargo, sería interesante leer sugerencias concretas sobre buenos paquetes para comenzar y las razones por las cuales serían buenos paquetes para comenzar.

También actualicé la pregunta anterior para referirme a "paquetes" en lugar de "paquete".

Sugeriría mirar el paquete del zoológico por las siguientes razones:

1. Tiene varias viñetas bien escritas;
2. Se utiliza un espacio de nombres utilizando useDynLib, import, export, y S3method;
3. Tiene varias pruebas unitarias usando RUnit;
4. Proporciona buenos ejemplos de cómo crear / documentar métodos S3;
5. Tiene algunas llamadas al código C a través de la .Callinterfaz;
6. Contiene una demostración (de trazado);
7. Su objetivo es ser coherente con la instalación del núcleo R (por ejemplo, las funciones se comportan de manera similar, no enmascaran / anulan las funciones base, etc.)

No usa roxygen, que es muy útil, pero 7 de 8 no está mal. ;-)

Para responder a sus criterios:

1. El concepto es simple: zooes una clase tipo matriz ordenada por algo . No se necesitan conocimientos específicos de dominio.
2. zoo parece tener algunas convenciones de codificación idiosincrásicas, pero nada exagerado que impida comprender el código.
3. zoo pretende ser tan consistente con R como sea posible.

No me considero un desarrollador de paquetes R establecido, pero recientemente me he sometido al proceso de escribir y mantener un paquete para mi entorno de trabajo.

Anteriormente había estado escribiendo / manteniendo / actualizando un conjunto de scripts que pasaría de un proyecto a otro a través de la source()función. El resultado final de esto fue que terminaría con scripts en su mayoría redundantes colgando en varios lugares en nuestras unidades de red. Nunca estuvo claro dónde se ubicaba el conjunto de scripts más actualizado. Desde entonces he migrado a escribir / mantener un paquete utilizando roxygen. Ha simplificado drásticamente mi vida y ha facilitado compartir mi trabajo con colegas.

Según sus criterios anteriores, secundo la recomendación de revisar los paquetes que Hadley ha escrito. En particular, creo que leer el wiki de devtools sería muy útil. El código de Hadley está bien documentado y varios de sus paquetes utilizan roxygen. Creo que escribir y mantener un documento para las funciones R y la documentación R es mucho más fácil que dividirlos en dos ubicaciones (archivos .R y .RD).

Los paquetes de Hadley también sirven algunos conceptos bastante básicos y son relativamente fáciles de eliminar (en mi humilde opinión) si está buscando sugerencias sobre las ideas de aspectos técnicos. Me encuentro cavando en el código fuente de plyr cuando busco un puntero en la documentación de roxygen u otras tareas fundamentales.

¿Por qué no adoptar un enfoque de muestreo aleatorio impulsado empíricamente? Solo elija algunos y vea cuál funciona para usted.

Bromas aparte, solo mira algunos paquetes que tú mismo usas y con los que estás familiarizado. Descargarlos es fácil, o si lo prefiere también puede verlos a través de una interfaz web en R-Forge, RForge o Github.

Lo más probable es que termines con diferentes paquetes para diferentes ideas. Algunos pueden ayudarlo con la forma en que se integran, digamos, una viñeta. Algunos pueden ayudar con el código compilado. O pruebas unitarias. O Roxygen. Hay alrededor de 2600 de ellos, entonces, ¿por qué obsesionarse con un solo mejor?

Otro consejo podría ser mirar los paquetes con los que dependerá o interactuará con usted, especialmente si implementan algunos elementos que Joshua Ulrich mencionó o han sido escritos por autores de renombre. Puede ser útil aprender cómo se hacen las cosas en su campo, para garantizar cierta compatibilidad. A menudo las personas habrán pensado en ciertos problemas y le será útil leer su solución migth.

Recomendaría el paquete de remodelación de Hadley. Puede encontrar la fuente en https://github.com/hadley/reshape