¿Cuál es su estilo preferido para nombrar variables en R? [cerrado]

¿Qué convenciones para nombrar variables y funciones prefiere en el código R?

Por lo que puedo decir, hay varias convenciones diferentes, todas las cuales coexisten en una armonía cacofónica:

1. Uso de separador de puntos, p. Ej.

  stock.prices <- c(12.01, 10.12)
  col.names    <- c('symbol','price')

Ventajas: tiene precedencia histórica en la comunidad R, prevalece en todo el núcleo R y es recomendada por la Guía de estilo R de Google .

Contras: lleno de connotaciones orientadas a objetos y confuso para los novatos de R

2. Uso de guiones bajos

  stock_prices <- c(12.01, 10.12)
  col_names    <- c('symbol','price')

Ventajas: una convención común en muchos idiomas de programación; favorecido por la Guía de estilo de Hadley Wickham y utilizado en los paquetes ggplot2 y plyr.

Contras: No históricamente utilizado por los programadores de R; está molestamente mapeado al operador '<-' en Emacs-Speaks-Statistics (modificable con 'ess-toggle-underscore').

3. Uso de capitalización mixta (camelCase)

  stockPrices <- c(12.01, 10.12)
  colNames    <- c('symbol','price')

Ventajas: parece tener una amplia adopción en varias comunidades lingüísticas.

Contras: Tiene un precedente reciente, pero no se ha utilizado históricamente (ni en la base R ni en su documentación).

Finalmente, como si no fuera lo suficientemente confuso, debo señalar que la Guía de estilo de Google aboga por la notación de puntos para las variables, pero la combinación de mayúsculas para las funciones.

La falta de estilo coherente en todos los paquetes de R es problemática en varios niveles. Desde el punto de vista del desarrollador, dificulta mantener y extender el código de otros (especialmente cuando su estilo es inconsistente con el suyo). Desde el punto de vista de un usuario de R, la sintaxis inconsistente hace que la curva de aprendizaje de R sea más pronunciada, al multiplicar las formas en que se puede expresar un concepto (por ejemplo, ¿esa función de conversión de fecha es comoDate (), as.date () o as_date ()? No, es como. Fecha()).

Buenas respuestas anteriores, así que solo un poco para agregar aquí:

• los guiones bajos son realmente molestos para los usuarios de ESS; dado que ESS se usa ampliamente, no verá muchos guiones bajos en el código creado por los usuarios de ESS (y ese conjunto incluye un montón de R Core y autores de CRAN, a pesar de excepciones como Hadley);

• los puntos también son malvados porque pueden mezclarse en un método simple de envío; Creo que una vez leí comentarios en este sentido en uno de la lista R: los puntos son un artefacto histórico y ya no se fomentan;

• así que tenemos un claro ganador que sigue en pie en la última ronda: camelCase. Tampoco estoy seguro de si estoy realmente de acuerdo con la afirmación de 'carecer de precedentes en la comunidad R'.

Y sí: el pragmatismo y la coherencia triunfan sobre el dogma. Entonces, lo que sea que funcione y sea utilizado por colegas y coautores. Después de todo, todavía tenemos espacios en blanco y llaves para discutir :)

Hice una encuesta sobre las convenciones de nomenclatura que se utilizan realmente en CRAN que fueron aceptadas en el R Journal :) Aquí hay un gráfico que resume los resultados:

Resulta (tal vez sin sorpresas) que lowerCamelCase se usaba con mayor frecuencia para los nombres de funciones y los nombres separados por períodos se usaban con mayor frecuencia para los parámetros. Sin embargo, usar UpperCamelCase, como lo recomienda la guía de estilo R de Google, es realmente raro, y es un poco extraño que defiendan el uso de esa convención de nomenclatura.

El artículo completo está aquí:

http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf

¡Subraya todo el camino! Contrariamente a la opinión popular, hay una serie de funciones en la base R que usan guiones bajos. Corre grep("^[^\\.]*$", apropos("_"), value = T)a verlos a todos.

Yo uso el estilo de codificación oficial de Hadley ;)

Me gusta camelCase cuando el camello proporciona algo significativo, como el tipo de datos.

dfProfitLoss, donde df = marco de datos

o

vdfMergedFiles (), donde la función toma un vector y escupe un marco de datos

Si bien creo que _ realmente aumenta la legibilidad, parece que hay demasiados problemas con el uso de.-_ U otros caracteres en los nombres. Especialmente si trabaja en varios idiomas.

Esto se reduce a preferencias personales, pero sigo la guía de estilo de Google porque es coherente con el estilo del equipo principal. Todavía tengo que ver un guión bajo en una variable en la base R.

Como señalo aquí:

¿Cómo afecta la verbosidad de los identificadores al rendimiento de un programador?

Vale la pena tener en cuenta lo comprensibles que son los nombres de sus variables para sus compañeros de trabajo / usuarios si no son hablantes nativos ...

Por esa razón, diría que los guiones bajos y los puntos son mejores que las mayúsculas, pero como señala, la coherencia es esencial dentro de su guión.

Como han mencionado otros, los guiones bajos arruinarán a mucha gente. No, no está prohibido, pero tampoco es particularmente común.

El uso de puntos como separador se vuelve un poco complicado con las clases S3 y similares.

En mi experiencia, parece que muchos de los mucks de R prefieren el uso de camelCase, con un poco de uso de puntos y un puñado de guiones bajos.

Por lo general, cambio el nombre de mis variables usando un ix de guiones bajos y una combinación de mayúsculas (camelCase). Las variables simples se nombran usando guiones bajos, ejemplo:

PSOE_votes -> número de votos del PSOE (grupo político de España).

PSOE_states -> Categórico, indica el estado donde gana PSOE (Aragón, Andalucía, ...)

PSOE_political_force -> Categorial, indica la posición entre los grupos políticos del PSOE {primero, segundo, tercero)

PSOE_07 -> Unión de PSOE_votes + PSOE_states + PSOE_political_force en 2007 (h eader -> votos, estados, posición )

Si mi variable es el resultado de una función aplicada en una / dos Variables, utilizo una capitalización mixta.

Ejemplo:

positionXstates <- xtabs (~ estados + posición, PSOE_07)

Tengo preferencia por las capitales mixtas.

Pero a menudo uso puntos para indicar cuál es el tipo de variable:

MixedCapitals.mat es una matriz. MixedCapitals.lm es un modelo lineal. MixedCapitals.lst es un objeto de lista.

y así.