[Pxr-commits] cambios en read.px --- estilo del código

[Oscar Perpiñan Lamigueiro]

>No es asunto baladí. Sobre todo cuando el código se escribe entre
>varios. Yo soy bastante quisquilloso con eso y me he ocupado del
>asunto previamente:
>
>1)
>http://www.datanalytics.com/blog/2010/11/01/una-propuesta-de-guia-de-estilo-de-r/
>2) http://www.datanalytics.com/guia_estilo_r.html
>
>Por ejemplo, en las llamadas a funciones, hay varias escuelas:
>
>1) foo(x,y)
>2) foo (x,y)
>3) foo( x, y )
>4) foo(x, y)
>5) y alguna combinación de las anteriores
>
>Me suelo decantar por la 3. Pero si nos gusta más la 4, por mí
>perfecto (que es la que "recomienda" google para R, por ejemplo).
>

En este tema creo que debemos atenernos a lo que ya hace R
"automáticamente" (si no me equivoco opta por la opción 4),
concretamente las funciones parse/deparse. Por cierto, hay un paquete
dedicado a estas tareas:
http://yihui.name/en/2010/04/formatr-farewell-to-ugly-r-code/.

>En la nomenclatura de funciones, pasa lo mismo:
>
>1) foo_bar
>2) fooBar
>3) foo.bar
>4) FooBar
>5) ¿otras?
>
>1 es la predilecta de quienes programan en C, Python, etc.
>Históricamente era impráctica en R porque al crear documentación en
>LaTeX, el _, que indica el subíndice, daba problemas. Aunque creo que
>eso ya está solucionado.
>
>Tradicionalmente en R se tendía a usar la 3, que recuerdo que me ponía
>nervioso porque en C y Java el "." no es un separador. (2) sería la
>preferida de los programadores en Java. Curiosamente, google se
>decanta por 4.
>
Hay un documento que recomienda (no lo encuentro) el uso de (2) para
nombrar variables y funciones, y reservar (4) para la definición de
clases nuevas (principalmente en el contexto de clases S4). Por lo que
veo, es el estilo más frecuente.

>También hay cuestiones relativas al tamaño de las indentaciones, el
>formato de los comentarios, etc.

En este tema yo optaría por las convenciones de ESS-Emacs (recomendado
en las FAQ de R:
http://cran.r-project.org/doc/manuals/R-FAQ.html#Should-I-run-R-from-within-Emacs_003f)
También hay recomendaciones de Bioconductor:
http://wiki.fhcrc.org/bioc/Coding_Standards

>
>Creo que todos tenemos estilos distintos y no estaría de más
>explicitar a cuál nos queremos atener para mantenerlo homogéneamente a
>través de todo el paquete. De hecho, uno de mis TODOs es crear un
>documento de estilo de para programar en R que mejore algunos de los
>aspectos que no me gustan del de google y creo que esta es una buena
>oportunidad para sacar a la luz pros y contras de las distintas
>opciones.

Sí, es una buena oportunidad. Vamos allá.

Oscar.
>Un saludo,
>
>Carlos J. Gil Bellosta
>http://www.datanalytics.com