varias recodificar lineas leyendas hacer graficos grafico graficas como barplot r coding-style naming-conventions

lineas - recodificar variables en r



¿Cuál es tu estilo preferido para nombrar variables en R? (9)

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

Uso el estilo oficial de codificación de Hadley ;)

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

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

1. Uso del separador de período, por ejemplo

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

Pros: tiene precedente histórico en la comunidad R, prevalente en todo el núcleo R y recomendado por la Guía de estilo R de Google .

Contras: abunda en connotaciones orientadas a objetos y confunde a los novatos R

2. Uso de guiones bajos

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

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

Contras: no utilizado históricamente por los programadores 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 amplia adopción en varias comunidades lingüísticas.

Contras: tiene un precedente reciente, pero no se usa históricamente (en la base R o su documentación).

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

La falta de estilo consistente en los paquetes R es problemática en varios niveles. Desde el punto de vista del desarrollador, dificulta y dificulta el mantenimiento y la extensión del código de otros (especialmente cuando su estilo no concuerda con el suyo). Desde el punto de vista del usuario R, la sintaxis incoherente agudiza la curva de aprendizaje de R, al multiplicar las formas en que se puede expresar un concepto (por ejemplo, ¿esa función de fechacast asDate (), as.date () o as_date ()? No, es como. Fecha()).

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

  • los subrayados son realmente molestos para los usuarios de ESS; dado que ESS es ampliamente utilizado, no verá muchos caracteres de subrayado en el código creado por los usuarios de ESS (y ese conjunto incluye un grupo de autores de R Core y CRAN, a pesar de las excpciones como Hadley);

  • los puntos también son malvados porque pueden mezclarse en el envío de métodos simples; Creo que una vez leí comentarios a este respecto en una de las listas R: los puntos son un artefacto histórico y ya no se fomentan;

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

Y sí: el pragmatismo y la consistencia triunfan sobre el dogma. Entonces, todo lo que funciona y lo usan colegas y coautores. Después de todo, todavía tenemos espacio en blanco y llaves para discutir :)

Como otros han mencionado, 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 pone un poco peludo con las clases S3 y similares.

En mi experiencia, parece que muchas de las porquerías de R prefieren el uso de camelCase, con cierto uso de puntos y un poco de guiones bajos.

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

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

Resulta (sin sorpresas quizás) que lowerCamelCase se usó con más frecuencia para los nombres de funciones y nombres de punto.separado que se usan con más 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 aboguen por usar esa convención de nomenclatura.

El documento completo está aquí:

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

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

dfProfitLoss, donde df = dataframe

o

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

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

Tengo una preferencia por mixedCapitals.

Pero a menudo uso períodos 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í.

Usualmente cambio el nombre de mis variables usando un ix de guiones bajos y una mayúscula mixta (camelCase). Las variables simples están nombrando usando guiones bajos, por ejemplo:

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

PSOE_states -> Categorical, indica el estado donde gana el 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 ( encabezado -> votos, estados, posición )

Si mi variable es un resultado de la función aplicada en una / dos variables I usando una mayúscula mixta.

Ejemplo:

positionXstates <- xtabs (~ states + position, PSOE_07)