R help es - Nov 2010 - Una guía de estilo para programar en R... ¿comentarios?

Hola, ¿qué tal?

Hace poco vi que Google había hecho pública su guía de estilo interna 
para programar en R:

http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html

Me tomé la libertad de traducirla:

http://datanalytics.com/guia_estilo_r.html

Cuanto más pienso en ella, más carencias veo. Escribí sobre ello en mi 
blog ( 
http://www.datanalytics.com/blog/2010/11/01/una-propuesta-de-guia-de-estilo-de-r/
). Las dos pegas principales que le veo son:

1) Que no hace mención a los paquetes (y cómo pueden utilizarse para 
gestionar la documentación de las funciones, etc.).

2) Que parece una traslación directa de una guía de estilo de Python o 
Java, ignorando (algunas) particularidades específicas de R.

Creo que disponer de una buena guía de estilo es importante a la hora de 
elaborar código en equipo. Por eso quiero plantear las siguientes dos 
preguntas en la lista:

1) ¿Echáis algo de menos en la guía de Google? ¿Omite algo relevante? 
¿Qué experiencia tenéis al respecto? ¿Cuál es la mejor política a la 
hora de diseñar paquetes?

2) ¿Habría alguien interesado en colaborar para recoger estas nuevas 
propuestas y mantener una propuesta de guía de estilo de R que pueda 
servir a grupos de programadores?

Un saludo,

Carlos J. Gil Bellosta
http://www.datanalytics.com

Respetado Carlos J.

Excelente tu propuesta sobre el estilo de programación en R.

Me parece que vale la pena pensar en algunos aspecto que podría ayudar
a los programadores en R a unificar el estilo para facilitar la lectura
de código escrito en R.

Algunas ideas que se me vienen a la cabeza y son para debatirlas y
llegar a un acuerdo que nos beneficie a todos.

1. De las recomendaciones que se hace sobre el uso de variables
utilizando el punto me aparto de ese criterio debido a que el punto se
utiliza también como identificador de métodos en el sistema S3 y podría
dar lugar a mal entendidos.

2. Con respecto a la extensión de los scripts en R, preferiría la
extensión ".r", porque muchas veces comparto archivos tanto en windows
como en linux y como windows no distingue entre minúsculas y mayúsculas
en los nombres de los archivos produce problemas en sincronizadores como
dropbox.

3. Me gusta más el estilo "nomVar" para nombres de variables que el de
"nom.Var", y prefiero formas cortas y no tan largas como
"CalculateAveClicks" tanto en funciones como variables, por eso para
la función preferiría "CalcAveClks" por ejemplo.

4. Incluiría en la distribución general después de los comandos source y
library un campo para definir configuraciones generales como parámetros
del "par.settings", "paletas de colores", grupos de símbolos
"pch",
"par" de gráficos, etc.

5. Si algún archivo será mas adelante utilizado como "source" por otro
programa cambiar los "library" por "require", para ahorrar
tiempo al
llamar a paquetes.

6. Para hacer más universal los paquetes se recomendaría tener nombres
de funciones en inglés, solo que fácilmente el nombre de la función
podría entrar en conflicto con los nombres de otras funciones en
otro paquete. ¿Qué recomiendan que podemos hacer en este caso?

Seguimos en contacto y proponiendo algunas soluciones.

Kenneth

En mi opinión, y de cara a compartir el código, las guías de estilo son 
FUNDAMENTALES. Ahora bien, creo que deben ser lo más breves posibles: 
minimalistas. La idea es que no sea necesario tener en cuenta muchas 
reglas. Respecto de los nombres de objetos, creo que salvo reglas muy 
generales, y que tengan en cuenta particularidades de la sintaxis, es
mejor que cada proyecto defina y determine su propia nomenclatura.


Le he echado un vistazo a la guía y me parece Ok, quizás un poco extensa 
en los que a combinación de indentado y contrucción de bloques,
pero es muy complicado y pesado ser exhaustivo.


Bajo mi punto de vista, y además de nombre de ficheros, variables, 
etc..., incluye los aspectos más importantes, que creo son:
  - Indentado: fundamental para leer código, me gusta lo del doble esp.
  - Construcción de bloques: generalmente los abro y se cierro en lineas
    nuevas, pero es cierto que resulta mejor como se indica en la guía.
    OBS: Creo que se debería considerar el que los bloques de
    definición de funciones se abran y cierren en lineas nuevas.
  - Formato de comentarios, de TODOs, documentación propia para la
    definición de las funciones.
    OBS: Quizás puede resultar interesante incluir como cabecera del
    fichero unos comentarios(en un formato determinado) indicando Autor,
    Copyright, descripción con la finalidad del código,...

Saludos, Jorge.



El 02/11/10 23:29, Carlos J. Gil Bellosta escribió:
> Hola, ¿qué tal?
>
> Hace poco vi que Google había hecho pública su guía de estilo interna
> para programar en R:
>
> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>
> Me tomé la libertad de traducirla:
>
> http://datanalytics.com/guia_estilo_r.html
>
> Cuanto más pienso en ella, más carencias veo. Escribí sobre ello en mi
> blog (
>
http://www.datanalytics.com/blog/2010/11/01/una-propuesta-de-guia-de-estilo-de-r/
> ). Las dos pegas principales que le veo son:
>
> 1) Que no hace mención a los paquetes (y cómo pueden utilizarse para
> gestionar la documentación de las funciones, etc.).
>
> 2) Que parece una traslación directa de una guía de estilo de Python o
> Java, ignorando (algunas) particularidades específicas de R.
>
> Creo que disponer de una buena guía de estilo es importante a la hora de
> elaborar código en equipo. Por eso quiero plantear las siguientes dos
> preguntas en la lista:
>
> 1) ¿Echáis algo de menos en la guía de Google? ¿Omite algo relevante?
> ¿Qué experiencia tenéis al respecto? ¿Cuál es la mejor política a la
> hora de diseñar paquetes?
>
> 2) ¿Habría alguien interesado en colaborar para recoger estas nuevas
> propuestas y mantener una propuesta de guía de estilo de R que pueda
> servir a grupos de programadores?
>
> Un saludo,
>
> Carlos J. Gil Bellosta
> http://www.datanalytics.com
>
> _______________________________________________
> R-help-es mailing list
> R-help-es en r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>

A mi personalmente me ha chocado mucho la recomendación de no usar
clases S4.

Para la creación el paquete orloca estuve mirando el tema de las clases
y por lo que leí había entendido que las clases S3 estaban en vías de
"desaparación".

¿Qué opináis al respecto?

Saludos.

-- 
==Proyecto R-UCA
http://knuth.uca.es/R
r-uca en uca.es
Manuel Muñoz Márquez
===

Hola, ¿qué tal?

Pues sobre las clases S4 no tengo tanta experiencia. Como usuario,
trabajé bastante en su día cuando utilizaba Bioconductor. Y como
desarrollador, construí un paquete en el que definía una clase de ese
tipo.

Fue una experiencia bastante frustrante: mis cañonazos malhirieron la
mosca paro no la mataron del todo. En la versión final del paquete se
cayó la clase S4. Y, personalmente, trataré de evitarlas en la medida
de lo posible. En eso convenimos Google y yo.

Recuerdo que durante mi periodo de máxima frustración hablé con Ramón
Díaz Uriarte que, si no recuerdo mal, me desaconsejó su uso. Y me
comentó que había algún/os peso/s pesado/s de R que se habían
pronunciado en el mismo sentido. No sé si tendrá algo que añadir (y si
he errado en el sentido de la cita, espero que no se lo tenga
demasiado en cuenta a mi floja memoria).

Creo que las clases S3 están para quedarse. No sé hasta qué punto la
complejidad añadida que supone el uso de clases S4 van a contribuir a
su popularización. Además, existen alternativas a las clases S3 y S4
(p.e., http://cran.r-project.org/web/packages/proto/) que bien
pudieran imponerse. De hecho, "proto" es el motor del "paquete
revelación" de R que es ggplot2.

Un saludo,

Carlos J. Gil Bellosta
http://www.datanalytics.com


El día 4 de noviembre de 2010 11:29, r-uca <r-uca en uca.es>
escribió:
> A mi personalmente me ha chocado mucho la recomendación de no usar
> clases S4.
>
> Para la creación el paquete orloca estuve mirando el tema de las clases
> y por lo que leí había entendido que las clases S3 estaban en vías de
> "desaparación".
>
> ¿Qué opináis al respecto?
>
> Saludos.
>
> --
> ==> Proyecto R-UCA
> http://knuth.uca.es/R
> r-uca en uca.es
> Manuel Muñoz Márquez
> ==>
> _______________________________________________
> R-help-es mailing list
> R-help-es en r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>

2010/11/4 Carlos J. Gil Bellosta <cgb en
datanalytics.com>:
> Hola, ¿qué tal?
>
> Pues sobre las clases S4 no tengo tanta experiencia. Como usuario,
> trabajé bastante en su día cuando utilizaba Bioconductor. Y como
> desarrollador, construí un paquete en el que definía una clase de ese
> tipo.
>
> Fue una experiencia bastante frustrante: mis cañonazos malhirieron la
> mosca paro no la mataron del todo. En la versión final del paquete se
> cayó la clase S4. Y, personalmente, trataré de evitarlas en la medida
> de lo posible. En eso convenimos Google y yo.
>
> Recuerdo que durante mi periodo de máxima frustración hablé con Ramón
> Díaz Uriarte que, si no recuerdo mal, me desaconsejó su uso. Y me
> comentó que había algún/os peso/s pesado/s de R que se habían
> pronunciado en el mismo sentido. No sé si tendrá algo que añadir (y si
> he errado en el sentido de la cita, espero que no se lo tenga
> demasiado en cuenta a mi floja memoria).
>

La memoria de Carlos (al menos en este punto) anda perfectamente ;-).



Pego aquí algunos enlaces que tengo al respecto:

http://article.gmane.org/gmane.comp.lang.r.general/159123/match=s4+vs+s3

http://www.mail-archive.com/r-devel en r-project.org/msg10977.html

http://osdir.com/ml/lang.r.devel/2007-02/msg00149.html

http://tolstoy.newcastle.edu.au/R/e4/devel/08/01/0064.html

http://tolstoy.newcastle.edu.au/R/e6/help/09/02/4595.html

http://search.gmane.org/search.php?group=gmane.comp.lang.r.general&query=s4+vs+s3



Hay comentarios de Frank Harell, Brian Ripley, Terry Therneau, etc. El
último enlace, en particular, es de un largo thread. Dicho lo
anterior, hay otros que prefieren con mucho S4 (ej., veanse libros de
R. Gentleman y J. Chambers), y S4 es el tipo de OOP "oficial" de
BioConductor. Pero si uno revisa los archivos de BioC (hace más de 5
años?), verá que no todo el mundo (incluyendo algunos nombres
ilustres) era entusiasta de S4.


Personalmente, yo evito las clases S4 por las razones que comenta
Carlos y las que figuran en el thread anterior. Nunca he entendido qué
me aportarían (pero sí veo lo que me quitarían y los problemas que me
añadirían).



R.



> Creo que las clases S3 están para quedarse. No sé hasta qué punto la
> complejidad añadida que supone el uso de clases S4 van a contribuir a
> su popularización. Además, existen alternativas a las clases S3 y S4
> (p.e., http://cran.r-project.org/web/packages/proto/) que bien
> pudieran imponerse. De hecho, "proto" es el motor del
"paquete
> revelación" de R que es ggplot2.
>
> Un saludo,
>
> Carlos J. Gil Bellosta
> http://www.datanalytics.com
>
>
> El día 4 de noviembre de 2010 11:29, r-uca <r-uca en uca.es>
escribió:
>> A mi personalmente me ha chocado mucho la recomendación de no usar
>> clases S4.
>>
>> Para la creación el paquete orloca estuve mirando el tema de las clases
>> y por lo que leí había entendido que las clases S3 estaban en vías de
>> "desaparación".
>>
>> ¿Qué opináis al respecto?
>>
>> Saludos.
>>
>> --
>> ==>> Proyecto R-UCA
>> http://knuth.uca.es/R
>> r-uca en uca.es
>> Manuel Muñoz Márquez
>> ==>>
>> _______________________________________________
>> R-help-es mailing list
>> R-help-es en r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>
>
> _______________________________________________
> R-help-es mailing list
> R-help-es en r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>


-- 
Ramon Diaz-Uriarte
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz
Phone: +34-91-732-8000 ext. 3019
Fax: +-34-91-224-6972

Hola,

He encontrado estas R Code Conventions (basadas en un documento para Java, según
parece):

http://www1.maths.lth.se/help/R/RCC/

y este otro documento (mucho más breve y menos estructurado): 

http://www.ci.tuwien.ac.at/Conferences/useR-2004/Keynotes/Maechler.pdf

Desde hace algo menos de un año utilizo Emacs Speaks Statistics (ESS) y, una vez
superado el aprendizaje inicial, me resulta impresionantemente útil para
construir código organizado, limpio y legible (en la medida de mis posibilidades
:-)). Quizás las convenciones (en cuanto a indentado, principalmente) que emplea
ESS pudiesen entrar en esta "guía de estilo".

Saludos.

-- 
Oscar Perpiñán Lamigueiro
Profesor Ayudante Doctor
Dpto. de Ingeniería Eléctrica
EUITI-UPM


On Tue, 02 Nov 2010 23:29:29 +0100
"Carlos J. Gil Bellosta" <cgb en datanalytics.com> wrote:
> Hola, ¿qué tal?
> 
> Hace poco vi que Google había hecho pública su guía de estilo interna 
> para programar en R:
> 
> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
> 
> Me tomé la libertad de traducirla:
> 
> http://datanalytics.com/guia_estilo_r.html
> 
> Cuanto más pienso en ella, más carencias veo. Escribí sobre ello en mi 
> blog ( 
>
http://www.datanalytics.com/blog/2010/11/01/una-propuesta-de-guia-de-estilo-de-r/
> ). Las dos pegas principales que le veo son:
> 
> 1) Que no hace mención a los paquetes (y cómo pueden utilizarse para 
> gestionar la documentación de las funciones, etc.).
> 
> 2) Que parece una traslación directa de una guía de estilo de Python o 
> Java, ignorando (algunas) particularidades específicas de R.
> 
> Creo que disponer de una buena guía de estilo es importante a la hora de 
> elaborar código en equipo. Por eso quiero plantear las siguientes dos 
> preguntas en la lista:
> 
> 1) ¿Echáis algo de menos en la guía de Google? ¿Omite algo relevante? 
> ¿Qué experiencia tenéis al respecto? ¿Cuál es la mejor política a la 
> hora de diseñar paquetes?
> 
> 2) ¿Habría alguien interesado en colaborar para recoger estas nuevas 
> propuestas y mantener una propuesta de guía de estilo de R que pueda 
> servir a grupos de programadores?
> 
> Un saludo,
> 
> Carlos J. Gil Bellosta
> http://www.datanalytics.com
> 
> _______________________________________________
> R-help-es mailing list
> R-help-es en r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es

Hola. 

Contesto sobre el correo.

On Fri, 5 Nov 2010 13:11:15 +0100
Ramon Diaz-Uriarte <rdiaz02 en gmail.com> wrote:
> 2010/11/4 Carlos J. Gil Bellosta <cgb en datanalytics.com>:
> > Fue una experiencia bastante frustrante: mis cañonazos malhirieron la
> > mosca paro no la mataron del todo. En la versión final del paquete se
> > cayó la clase S4. Y, personalmente, trataré de evitarlas en la medida
> > de lo posible. En eso convenimos Google y yo.
En mi opinión, el uso de S3 o S4 depende de los objetivos a conseguir. Yo he
construido un paquete basado casi en su totalidad en clases y métodos S4. Partía
de una versión anterior construida en S3, y me decidí a la conversión porque
necesitaba trabajar con objetos complejos, y emplear métodos que fuesen capaces
de reaccionar a "signatures" mixtas. Después del esfuerzo de
aprendizaje y reescritura, estoy convencido de las bondades de S4, y convencido
también de que las funcionalidades de la versión actual del paquete no las
habría conseguido con S3 (al menos no de una forma limpia y robusta).
> > Recuerdo que durante mi periodo de máxima frustración hablé con Ramón
> > Díaz Uriarte que, si no recuerdo mal, me desaconsejó su uso. Y me
> > comentó que había algún/os peso/s pesado/s de R que se habían
> > pronunciado en el mismo sentido. No sé si tendrá algo que añadir (y si
> > he errado en el sentido de la cita, espero que no se lo tenga
> > demasiado en cuenta a mi floja memoria).
> >
 
> Pego aquí algunos enlaces que tengo al respecto:
Buena lista de enlaces, muy ilustrativo. Gracias! Supongo que cada uno prestamos
más atención a lo que queremos escuchar, pero después de haberme recorrido estos
"thread" yo percibo una opinión ampliamente favorable hacia S4...
 
> 
> Hay comentarios de Frank Harell, Brian Ripley, Terry Therneau, etc. El
> último enlace, en particular, es de un largo thread. Dicho lo
> anterior, hay otros que prefieren con mucho S4 (ej., veanse libros de
> R. Gentleman y J. Chambers), y S4 es el tipo de OOP "oficial" de
> BioConductor. Pero si uno revisa los archivos de BioC (hace más de 5
> años?), verá que no todo el mundo (incluyendo algunos nombres
> ilustres) era entusiasta de S4.
En la actualidad, más del 50% de los paquetes de BioC están construidos en S4:
http://www.bioconductor.org/help/course-materials/2010/AdvancedR/S4InBioconductor.pdf.
> > Creo que las clases S3 están para quedarse. No sé hasta qué punto la
> > complejidad añadida que supone el uso de clases S4 van a contribuir a
> > su popularización. Además, existen alternativas a las clases S3 y S4
> > (p.e., http://cran.r-project.org/web/packages/proto/) que bien
> > pudieran imponerse. 
"proto" lo utilizan 11 paquetes en CRAN, y de ellos 3 están escritos
por el "maintainer" de
"proto". No sé cual será el futuro de S4, pero teniendo en cuenta que
proto empezó en el 2005, no parece una alternativa muy potente.
Y parece que su aplicación es más reducida: el "maintainer" de proto
dice que "proto tends to apply in user interface applications"
(http://tolstoy.newcastle.edu.au/R/e8/help/09/10/2601.html).


Sea como sea, como decía al principio, opino que hay que elegir (o construir)
las herramientas adecuadas para lo que se necesita, sean S3, S4 o lo que surja.

Saludos.

Oscar.

On Thu, 4 Nov 2010 17:42:12 +0100
"Carlos J. Gil Bellosta " <cgb en datanalytics.com>
wrote:
> De hecho, "proto" es el motor del "paquete
> revelación" de R que es ggplot2.
...para gustos hay colores, y nunca mejor dicho en esto de las herramientas
gráficas. Es verdad que "ggplot2" y su autor aparecen aquí y allá en
blogs, presentaciones y cursos. Si es por esta presencia masiva, estoy de
acuerdo en que es el paquete revelación. Pero, sin ánimo de abrir una guerra de
opiniones y sin desmerecer sus grandes cualidades como herramienta, creo que
está sobrevalorado (algunas veces parece como si R se redujese a ggplot2) y
rodeado de un ambiente demasiado apasionado
(http://www.r-bloggers.com/hadley-on-a-postage-stamp/).

Yo utilizo habitualmente lattice. En alguna ocasión, por curiosidad he
jugueteado con ggplot2, y no he encontrado razones para utilizarlo de forma
habitual. Lo cual no significa que no sean interesantes algunas de sus
funciones: por ejemplo, latticeExtra ha incorporado algunas ideas en funciones
como glayer o panel.smoother.

Para una comparativa (con código frio y desapasionado ;-)) puede ser útil esta
cadena de 13
entradas:http://learnr.wordpress.com/2009/06/28/ggplot2-version-of-figures-in-lattice-multivariate-data-visualization-with-r-part-1/.

Saludos.

Oscar.
-- 
Oscar Perpiñán Lamigueiro
Profesor Ayudante Doctor
Dpto. de Ingeniería Eléctrica
EUITI-UPM