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

[Carlos J. Gil Bellosta]

Hola, ¿qué tal?

Respondo, como siempre, abajo.

El día 30 de agosto de 2011 14:55, Oscar Perpiñan Lamigueiro
<oscar.perpinan at upm.es> escribió:
>>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/.

Reconozco y me confieso un talibán del espaciado. Pero me parece bien
(4). Pero tendría en cuenta la salvedad (punto 74) de
http://geosoft.no/development/javastyle.html: en algunas ocasiones,
cuando se juntan dos nombres largos, en lugar de usar necesariamente

doSomething(currentFile)

dar la libertad para usar

doSomething( currentFile )

para separar las cadenas de texto (largas) y que resalten individualmente.


>>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.

Desafortunadamente, no hay consistencia ni en el paquete base de R.
Ahi nos encontramos funciones como

is.character (etc.)
cumsum (no cum.sum ni cumSum)
rowSums (voilá!)

e incluso alguna que no recuerdo que usa "_" como separador.

La única solución que veo a la inconsistencia es ser consistente en
ella. No se justificaría usar readPx sino read.px (como read.table,
etc.). Ni is_px por el mismo motivo.

Estoy seguro de que quienes vienen del universo Java preferirán
doSomething. Los que vengan de Python o C preferirán do_something o su
versión eRReficada, do.something.

Por tanto, mi propuesta es:

1) Ser consistente con la tradición donde sea "casi obligatorio"
(is.px, read.px, etc.).
2) Tirar una moneda al aire para optar entre doThis o do.this (es
broma: yo me adapto a lo que haya según la circunstancia).
3) Mantener luego la uniformidad en el paquete entero.


>>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)

Nunca me gustaron las indentaciones de ESS por defecto: cuando lo
usaba, indentaba con 2 espacios y yo lo encuentro escaso. Fuera de
eso, no veo problema... ¡salvo que no uso Emacs ya!

> También hay recomendaciones de Bioconductor:
> http://wiki.fhcrc.org/bioc/Coding_Standards

Algunas son opinables. Como talibán del espacio que soy, no me gusta
aceptar a rajatabla que, por ejemplo, no haya que dejar espacio nunca
alrededor del =

hacerCompra(verdura="lechuga")

me parece inferior a

hacerCompra(verdura = "lechuga")

e incluso opinaría que a

hacerCompra( verdura = "lechuga" )

Debería tal vez haber recomendaciones distintas a para

f(x=1, y=2)

que para casos en que los nombres de las variables sean
sustancialmente más largos (y no un "one size fits all").

Un saludo,

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