herramienta - lenguaje r



Práctica de codificación en R: ¿Cuáles son las ventajas y desventajas de los diferentes estilos? (3)

Escribo funciones (en archivos .R independientes) para varios trozos de código que conceptualmente hacen una cosa. Esto mantiene las cosas cortas y dulces. Encontré la depuración algo más fácil, porque traceback() te da qué función produjo un error.

Yo también tiendo a evitar los bucles, excepto cuando es absolutamente necesario. Me siento un poco sucio si uso un bucle for() . :) Intento realmente hacer todo vectorizado o con la familia de aplicaciones. Esta no es siempre la mejor práctica, especialmente si necesita explicar el código a otra persona que no es tan fluida en aplicar o vectorizar.

En cuanto al uso de require vs :: , tiendo a usar ambos. Si solo necesito una función de un determinado paquete, la uso a través de :: , pero si necesito varias funciones, cargo todo el paquete. Si hay un conflicto en los nombres de funciones entre paquetes, intento recordar y usar :: .

Intento encontrar una función para cada tarea que intento lograr. Creo que alguien antes que yo lo ha pensado e hizo una función que funciona mejor que cualquier otra cosa que se me ocurra. Esto a veces funciona, a veces no tanto.

Intento escribir mi código para poder entenderlo. Esto significa que comento mucho y construyo trozos de código para que de alguna manera sigan la idea de lo que estoy tratando de lograr. A menudo sobrescribo objetos a medida que avanza la función. Creo que esto mantiene la transparencia de la tarea, especialmente si se refiere a estos objetos más adelante en la función. Pienso en la velocidad cuando el tiempo de cálculo excede mi paciencia. Si una función tarda tanto en terminar que empiezo a navegar SO, veo si puedo mejorarla.

Descubrí que un buen editor de sintaxis con doblado de código y coloreado de sintaxis (uso Eclipse + StatET) me ha ahorrado muchos dolores de cabeza.

Basado en la publicación de VitoshKa, agrego que uso palabras en mayúscula (sensu Java) para nombres de funciones y fullstop.delimited para variables. Veo que podría tener otro estilo para los argumentos de función.

https://ffff65535.com

Las preguntas recientes sobre el uso de require versus :: plantearon la pregunta sobre qué estilos de programación se usan al programar en R y cuáles son sus ventajas / desventajas. Navegando por el código fuente o navegando en la red, verá una gran cantidad de estilos diferentes que se muestran.

Las principales tendencias en mi código:

  • vectorización pesada Juego mucho con los índices (y los índices anidados), lo que a veces da como resultado códigos bastante oscuros, pero en general es mucho más rápido que otras soluciones. Ejemplo: x[x < 5] <- 0 lugar de x <- ifelse(x < 5, x, 0)

  • Tiendo a anidar funciones para evitar sobrecargar la memoria con objetos temporales que necesito limpiar. Especialmente con funciones que manipulan grandes conjuntos de datos, esto puede ser una carga real. eg: y <- cbind(x,as.numeric(factor(x))) vez de y <- as.numeric(factor(x)) ; z <- cbind(x,y) y <- as.numeric(factor(x)) ; z <- cbind(x,y)

  • Escribo muchas funciones personalizadas , incluso si uso el código solo una vez en, por ejemplo. una sapply . Creo que lo mantiene más legible sin crear objetos que puedan permanecer por ahí.

  • Evito los lazos a toda costa , ya que considero que la vectorización es mucho más limpia (y más rápida)

Sin embargo, me he dado cuenta de que las opiniones sobre esto difieren, y algunas personas tienden a alejarse de lo que llamarían mi forma de programación "Perl" (o incluso "Lisp", con todos esos corchetes volando en mi código. sin embargo, vaya tan lejos).

¿Qué consideras una buena práctica de codificación en R?

¿Cuál es tu estilo de programación y cómo ves sus ventajas y desventajas?


Las convenciones de nomenclatura son extremadamente importantes para la legibilidad del código. Inspirado por el estilo interno de R S4 aquí es lo que uso:

  • camelCase para funciones y objetos globales (como doSomething, getXyyy, upperLimit)
  • las funciones comienzan con un verbo
  • no exportado y las funciones de ayuda siempre comienzan con "."
  • las variables locales y las funciones están todas en minúsculas y en la sintaxis "_" (do_something, get_xyyy), hace que sea fácil distinguir local vs global y por lo tanto conduce a un código más limpio.

Para los malabares de datos, trato de usar tanto SQL como sea posible, al menos para las cosas básicas como los promedios de GROUP BY. Me gusta mucho R pero a veces no solo es divertido darse cuenta de que su estrategia de investigación no fue lo suficientemente buena como para encontrar otra función escondida en otro paquete. Para mis casos, los dialectos SQL no difieren mucho y el código es realmente transparente. La mayoría de las veces, el umbral (cuándo comenzar a usar la sintaxis R) es bastante intuitivo de descubrir. p.ej

require(RMySQL)
# selection of variables alongside conditions in SQL is really transparent
# even if conditional variables are not part of the selection
statement = "SELECT id,v1,v2,v3,v4,v5 FROM mytable
             WHERE this=5
             AND that != 6" 
mydf <- dbGetQuery(con,statement)
# some simple things get really tricky (at least in MySQL), but simple in R
# standard deviation of table rows
dframe$rowsd <- sd(t(dframe))

Así que considero que es una buena práctica y realmente recomiendo usar una base de datos SQL para sus datos para la mayoría de los casos de uso. También estoy investigando TSdbi y guardando series de tiempo en la base de datos relacional, pero realmente no puedo juzgar eso todavía.





vectorization