8 consejos de estilo de codificación para la programación R

buen software Un buen software se puede juzgar leyendo algún fragmento de código escrito en el proyecto.

Si el código es fácil de entender y cambiar, definitivamente es un buen software y a los desarrolladores les encanta trabajar en eso. Para un programador principiante de R, es una buena idea adquirir y comenzar a usar buenas prácticas en codificación. Google y R-guru Hadley Wickham tienen excelentes consejos sobre la guía de estilo de codificación R. La lista contiene cosas que hacer y no hacer al programar en R. Entonces, en este artículo vamos a discutir seis consejos de estilo de codificación que lo ayudarán a convertirse en un mejor programador en lenguaje R.

1. Comentando

un tercero comienza a comentar una línea con el símbolo de comentario # y un espacio . Hadley Wickham sugiere usar el resto de las líneas comentadas con – y = para dividir el archivo en partes fáciles de leer. Consulte el siguiente fragmento de código de muestra: 

# Read table ----------------------------------
# Read table ==================================

2. Asignación

R tiene un operador de asignación inusual ‘<-‘ en lugar del signo ‘=’. Por lo tanto, es una buena práctica usar el signo ‘<-‘, en lugar del signo ‘=’ . Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
x <- 10

Mala práctica:

# Bad Practice
x = 10

3. Nombres de archivos

El nombre del archivo debe ser significativo y terminar con ‘.R’ . Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
fit-models.R
linear-regression.R

Mala práctica:

# Bad Practice
models.R
stuff.R

Si los archivos deben ejecutarse en secuencia, prefijelos con números como se muestra a continuación:

0-fit-models.R
1-linear-regression.R
2-neural-network.R

4. Nombres de objetos

«Solo hay dos cosas difíciles en Ciencias de la Computación: invalidación de caché y nombrar cosas».

—Phil Karlton

Los nombres de variables y funciones deben estar en minúsculas . Use un guión bajo ‘_’ para separar palabras dentro de un nombre. Generalmente, los nombres de las variables deben ser sustantivos y los nombres de las funciones deben ser verbos. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
number_of_students
get_price

Mala práctica:

# Bad Practice
GetPrice
getprice

5. Espaciado

Coloque espacios alrededor de todos los operadores infijos ( =, +, -, <-, etc. ). La misma regla se implementa cuando se usa = en llamadas a funciones. Siempre ponga un espacio después de una coma, y ​​nunca antes. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
perimeter_of_rectangle = 2(length + width), na.rm = TRUE)

Mala práctica:

# Bad Practice
perimeter_of_rectangle=2(length+width),na.rm=TRUE)

Hay una pequeña excepción a esta regla, por ejemplo, en el caso de :,::y ::: no necesitan espacios alrededor de ellos. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
x <- 1:20
value::real

Mala práctica:

# Bad Practice
x <- 1 : 20
value :: real

Ponga un espacio antes de los paréntesis izquierdos, excepto en una llamada de función. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
if (yes) do(x)
run(x, y)

Mala práctica:

# Bad Practice
if(yes)do(x)
run(x, y)

No coloque espacios alrededor del código entre paréntesis o corchetes excepto que haya una coma. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
student[1, ]

Mala práctica:

# Bad Practice
  
# Needs a space after the comma
student[1,]
  
# Put space after comma not before
student[1 ,]

6. Tirantes rizados

Una llave de apertura nunca debe ir en su propia línea y siempre debe ir seguida de una nueva línea. Una llave de cierre siempre debe ir en su propia línea a menos que sea seguida por otra cosa. Siempre sangre el código dentro de llaves. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
if (x > 0 && foo) {
  cat("X is positive")
}
  
if (x == 0) {
  log(a)
} else {
  a ^ x
}

Mala práctica:

# Bad Practice
  
if (x > 0 && foo)
cat("X is positive")
  
if (x == 0) {
  log(a)
} 
else {
  a ^ x
}

mostrado

# Good Practice
if (x > 0 && foo) cat("X is positive")

7. Longitud de línea

8. sangría

Al sangrar su código, use dos espacios . Nunca utilice tabulaciones ni mezcle tabulaciones y espacios. La única excepción es si una definición de función se ejecuta en varias líneas. En ese caso, sangre la segunda línea donde comienza la definición. Consulte el siguiente fragmento de código de muestra: 

Buena práctica:

# Good Practice
function_name <- function(a = "a long argument", 
                          b = "another argument",
                          c = "another long argument") {
  # As usual code is indented by two spaces
}