Hay muchas formas de escribir código en R. Entre mas código escribes, y sobretodo entre mas código tienes que leer, más apreciaras un estilo uniforme. Te permitirá leer tu propio código y volver a entenderlo mas fácilmente después de un largo tiempo sin haberlo visto. Ademas, un estilo uniforme te permitirá trabajar mas efectivamente con otros.
Cuando empiezas a trabajar en equipo es buena práctica ponerse de acuerdo de antemano sobre el estilo. Así quedará mas fácil entender el código de los demás, y será mas fácil cuando un nuevo miembro se una al equipo.
Aquí abajo presento los diferentes elementos que pueden estar en un guia de estilo. Esta basado en el guia de estilo de Hadley Wickham. Este a su vez esta basado en el guia de estilo de Google. Añado la sugerencias que son relevantes para hispanohablantes. Esto porque en el Castellano estamos acostumbrados, entre otras cosas, a tildes, eñes y otros caracteres que necesitan su propia discusión.
Hay una traducción al Español de la guia de estilo de Google de Carlos J. Gil Bellosta que tiene la ventaja de tener un breve resumen de las reglas de estilo. Esas 14 lineas constituyen el mínimo de puntos sobre los cuales necesitas llegar a un acuerdo para tener un estilo uniforme en tus proyectos.
Existen paquetes para formatear código automáticamente, especialmente formatR de Yihui Xie. Estos son útiles, pero pueden tener diferencias a lo acordado en tu equipo. En la práctica muchas veces es recomendable arreglar código a mano. Al leer y revisar código para verificar detalles de estilo muchas veces encuentras errores que de otra forma no habrías visto.
Espero que esto te ayude como base para tu estilo personal, o el de tu grupo de investigación o equipo de trabajo. Quedo atento a cualquier corrección o punto de mejora que puedas aportar.
Nombres de archivos deben tener un nombre descriptivo, no tener caracteres especiales (tildes, eñes) y terminar en .R.
# Bien
modelo-predictivo.R
lectura-datos.R
# Mal
código-añejo.r
versiondellunes.r
Si tu solución o estudio requiere que los archivos se corran en una secuencia predeterminada, añade prefijos con numerales:
0-importar-datos.R
1-analisis-exploratorio.R
2-modelo-predictivo.R
La guia de Google da una recomendación diferente a la de Wickam sobre el uso de guiones bajos (_) y guiones (-) para separar palabras. No hay un consenso (Baath 2012) entre autores, pero la recomendación de Wickam es la mas actual. El recomienda que en general nombres de variables y de funciones deben ser en minúscula y que se ha de usar un guión bajo (_) para separar palabras dentro de un nombre. Toma en cuenta de que no es fácil encontrar nombres que son cortos y autoexplicativos a la vez, pero trata de encontrarlos. Wickham tambien recomienda usar sustantivos para los nombres de las variables y verbos para las funciones. Nunca uses caracteres especiales como tildes y eñes en tus nombres de objetos.
# Bien
primer_cuartil
cuartil_1
# Mal
primer-cuartil
CuartilUno
C1
está_en_el_primer_cuartil
Si usas nombres de funciones que ya están en uso es probable que generes confusión. Trata de evitarlo hasta donde sea posible.
# Mal
F <- TRUE
any <- 24
ls <- function(x) read.table(x)
Antes y después de todos los operadores infijos va un espacio (=, +, <-, etc). Esto aplica aún para el signo equivalente (=) en las llamada de una función. No hay espacios antes de una coma, pero una coma siempre es seguida por un espacio.
# Bien
profundidad <- round((pies + pulgadas / 12), digits = 2)
# Mal
profundidad<-round((pies+pulgadas/12),digits=2)
La excepción a esta regla es cuando se usan :, :: y :::
# Bien
x <- 2:23
base::round
# Mal
x <- 2 : 23
base :: round
Antes del paréntesis izquierdo va un espacio, a no ser que estés llamando una función en cual caso no se usa un espacio.
# Bien
if (debug) do(x)
qplot(x, y)
# Mal
if(debug)do(x)
qplot (x, y)
Cuando quieras introducir mas orden en el código alineándolo, por ejemplo, sobre los símbolos de igualdad esta bien usar espacios para tal efecto.
data.frame(
nombres = c("Maria", "José", "John"),
resultados = c(7, 3, 8),
primera_vez = c(TRUE, FALSE, TRUE)
)
Los paréntesis y corchetes ([]) no llevan espacios a su alrededor. Si hay una coma, aplican las convenciones que se mencionaron antes.
# Bien
if (depurando) x <- 34
resultados[5, 1]
# Mal
if ( depurando ) x <- 34# no pongas espacias alrededor de tu variable
resultados[1,] # falta un espacio detrás de la coma
resultados[1 ,] # un espacio demás antes y de menos después de la coma
No uses punto y coma dentro del código. No es necesario, y prácticamente ya no se usa.
# Bien
print("El resultado:")
print(x)
cat("El resultado: \n", x)
# Mal
print("El resultado:"); print(x)
Abrir una llave nunca debería ocurrir en su propia linea y siempre se sigue
con una linea nueva. Una llave que cierra siempre debe ir en su propia
linea a menos que sea else. Siempre usa llaves cuando estas usando
construcciones con "if", aun cuando no es posible no hacerlo.
Para visualizar mejor de que se trata de un bloque, siempre usa sangría para el código dentro de llaves, aún cuando se trata de una sola línea.
# Bien
if (x != 0 && depurando) {
cat("x no es 0 pero:", x)
}
if (x == 0) {
0
} else {
z / x
}
# Mal
if (x != 0 && depurando)
cat("x no es 0 pero:", x)
if (x == 0) {
0
} else {
z / x
}
Trata de limitar tu código a una longitud de 80 caracteres por linea. Esto cabe cómodamente en una página impresa a un tamaño de la fuente razonable. Si encuentras que no tienes suficiente espacio, esto es una buena indicación de que deberías encapsular alguna parte del trabajo en una función separada.
Usa dos espacios para añadir una sangría a tu código y nunca usa la tecla TAB. Si te encuentras con código que usa una mezcla de espacios y TABs, cámbialo inmediatamente al uso exclusivo de espacios.
Hay una excepción a esta regla cuando tu función corre sobre mas de una linea. Para formatear el código de forma legible en esto casos, corre la sangría de la segunda linea para alinear los componentes de la función.
nombre_de_objecto_largo <- function(argumento_1 = "varias palabras"),
argumento_2 = "que corren hasta la siguiente linea"
argumento_3 = "pero se dejan leer de esta forma") {
# desde aquí usamos la sangría de dos espacios otra vez
}
Es mejor usar solo <- para asignación en vez de = y usar el símbolo de igualdad solamente para argumentos dentro de funciones.
# Bien
y <- 23
# Mal
y = 23
Usa comentarios en tu código. Cada linea debe comenzar con un símbolo de comentario (#) y un solo espacio: #. Los comentarios deben explicar el porque, y no el que.
Para separar y estructurar el código en pedazos se pueden usar cualquier carácter después de la tecla numeral (#). Común es el uso de más # o un separación con guiones - como aquí abajo. En ambos caso RStudio te va a ayudar a navegar el código.
### Gráfica principal ########################################################
# Añadimos comentarios para ayudar al lector del código
# Carga datos -----------------------------
# Lo importante de la separación no es como lo anotas pero donde lo pones.
Al trabajar en entornos con datos en Castellano, a veces tenemos nombres de fila y columnas que contienen caracteres no-ASCII. La mayoría de funciones en R no tiene problemas con estos, pero a veces se dan problemas. Para rápidamente cambiar los nombres a nombres validos se puede hacer lo siguiente.
nombres <- ("Abóbora", "Almendrón de Guaduas", "Araça vermelho")
# Para cambiarlos a nombre sintácticamente validos
make.names(nombres)
# Pare remover todo carácter no-ASCII
iconv(nombres, to='ASCII', sub='.')