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

[Carlos J. Gil Bellosta]

Hola, ¿qué tal?

> PD. Un comentario sin mayor importancia: veo que en parte del código
> hay espacios alrededor de los paréntesis. A mí me resulta extraño y, la
> verdad, algo incómodo para leer el código. ¿Los necesitáis así por
> alguna razón?

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

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

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.

Un saludo,

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