Estilos de Programación JavaScript: Mejores Prácticas

Cuando programas con JavaScript existen ciertas convenciones que deberías aplicar, especialmente cuando trabajas en un entorno de equipo. De hecho, es habitual mantener reuniones para debatir acerca de los estándares a seguir. El motivo es que el código resulta mucho más legible cuando se siguen ciertos estándares.

Ya hemos visto en otro artículo algunas de las peores prácticas de JavaScript, explicando ciertas cosas a evitar. Pero cuando hablamos de buenas prácticas no solo nos referimos a aquellas que tienen un mejor rendimiento, sino también a la forma en la que programas. Además de asegurarte de que el código sea sintácticamente correcto, también deberías preocuparte de los estilos; es decir, de cosas como el lugar en el que colocas las llaves de apertura y de cierre o de los espacios que usas como sangría o indentado en el código.

Contenidos

1 Qué son los estilos de programación
2 La importancia de los estilos
3 Conjuntos de estándares de estilos
4 Notación de métodos, funciones y variables
5 Qué reglas utilizar: Las Tuyas

Qué son los estilos de programación

Los estilos de programación no son más que un acuerdo que realizas tanto con tu equipo como contigo mismo acerca de los estilos y estándares que vas a seguir en un proyecto. El objetivo de seguir un estilo es el de lograr un resultado consistente, con código que sea fácil de entender y mantener.

Incluso aunque trabajes tú solo en un proyecto personal deberías seguir ciertos estándares. Quizás no veas el por qué durante su versión inicial, pero sí cuando modifiques el código dentro de unos meses o cuando otro programador comience también a trabajar en el proyecto.

La importancia de los estilos

La programación es algo así como un trabajo artesanal en el que intervienen factores como la creatividad, la constancia y la pericia. Por ejemplo, puedes pintar una pared y dejarla lisa, con todo perfectamente limpio a tu alrededor, o también puedes pintar la pared con irregularidades o marcas de manos, llenar el suelo de pintura y dejar todo tirado. Pues con la programación ocurre lo mismo, cobrando incluso más importancia, ya que cuando son muchos los programadores que modifican una y otra vez el mismo código, si cada uno aplica sus propias reglas el resultado puede parecerse más al segundo caso.

Es muy habitual que ciertos programadores con poca experiencia no se preocupen por esto, dado que aún no ha sido capaces de llegar a entender su importancia. Yo también fui uno de ellos y absolutamente todos los programadores lo hemos sido. Además es en este tipo de pequeñas cosas en donde los jefes de equipo percibirán tu experiencia.

Conjuntos de estándares de estilos

Existen diferente conjuntos de estándares que podrías seguir. Cada empresa tiene los suyos, y es que los estilos van de eso, de seguir los mismos en el marco de una empresa o proyecto, sin existir un conjunto que sea mejor o peor. Aquí tienes los dos conjuntos de estilos más famosos:

Por un lado tienes los estilos de JavaScript de Google
Por otro lado tienes los estilos de JavaScript de AirBnb

En mi caso, los estilos que sigo son muy parecidos a los de AirBnb, ya que son a los que me he acostumbrado en las empresas en las que he trabajado. Si prefieres otro conjunto úsalo, pero no lo cambies hasta que finalices el proyecto.

También tienes la opción de usar herramientas como ESLint o Prettier, que de algún modo te fuerzan a usar ciertas reglas.

Notación de métodos, funciones y variables

Existen diferentes tipos notaciones que podrías seguir cuando defines los nombres de funciones y variables. Los más famosos son los siguientes:

Camel Case: Este estilo combina las palabras de los nombres que definas, estableciendo que la primera letra de cada palabra esté en mayúscula a excepción de la primera palabra, estando el resto de letras en minúsculas. Si quisieses definir una función de gestión de cuentas mediante Camel Case su nombre sería gestionDeCuentas.
Pascal Case: Este estilo combina las palabras de los nombres que definas, estableciendo que la primera letra de cada palabra esté en mayúscula, incluyendo la primera palabra, estando el resto de letras en minúsculas. Si quisieses definir una función de gestión de cuentas mediante Pascal Case su nombre sería GestionDeCuentas.
Snake Case: Este estilo combina las palabras de los nombres que definas, estableciendo que todas las letras estén en minúscula y que todas las palabras se separen por un guión bajo. Si quisieses definir una función de gestión de cuentas mediante Snake Case su nombre sería gestion_de_cuentas.
Kebab Case: Este estilo combina las palabras de los nombres que definas, estableciendo que todas las letras estén en minúscula y que todas las palabras se separen por un guión. Si quisieses definir una función de gestión de cuentas mediante Snake Case su nombre sería gestion-de-cuentas.

No existe un método mejor, aunque lo cierto es que en JavaScript el Kebab Case estaría prácticamente descartado. Lo habitual es usar el Pascal Case para nombres de clases y Pascal Case para casi todo lo demás, aunque existen muchos desarrolladores que prefieren definir los nombres de las variables con Snake Case. Si quieres más ejemplos, consulta la guía con los diferentes tipos de notación para nombres.

Qué reglas utilizar: Las Tuyas

Así es y será mientras seas consistente. A continuación expongo las mías que si bien son muy parecidas a las de AirBnb, no coinciden al 100%:

Punto y coma: Muchos desarrolladores optan por no ponerlos al final de cada línea, aunque en mi caso los uso religiosamente al final de cada línea para evitar posibles problemas que podrían darse en algunos casos.
Espacios: Siempre prefiero usar espacios de más que de menos. Suelo utilizarlos siempre que cierro un paréntesis salvo que sea final de línea y también antes y después de los símbolos de operaciones aritméticas como +, -, / o *, comprobaciones o condiciones.
Líneas en blanco: Uso un salto de línea para separar bloques de código que se encargan de operaciones lógicas distintas. De este modo creo que es más fácil leer el código.
Sangrías: Uso 4 espacios en lugar de pulsar el tabulador. Es también habitual usar dos espacios.
Longitud de línea: La longitud de mis líneas no supera los 120 caracteres. Son muchos los desarrolladores que optan por 80 caracteres, pero a mi se me hace muy corto. Tengo la mala costumbre de usar líneas demasiado largas.
Comentarios: Suelo usar bloques de comentarios para documentar el código, y en caso de comentar algo, escribo el comentario en al línea superior a la que quiero comentar en lugar de escribirlo al final de la línea. Del mismo modo, solamente escribo los comentarios que son necesarios. Es decir, no uso comentarios cuando los bloques de código que siguen el estándar JSDoc son suficientes o cuando debido a los nombres de las variables resulta muy sencillo entender lo que se pretende hacer.
Declaraciones de variables: Nunca declaro variables con var. Utilizo const cuando un valor o referencia no va a cambiar, y let cuando quiero declarar una variable. Siempre declaro primero las constantes y después las variables, estando ambas al principio del documento en el caso de las variables globales, o al principio de las funciones, en el caso de las locales. De este modo evitamos los efectos indeseados de hoisting de JavaScript.
Estructura de las funciones: Utilizo funciones flecha siempre que sea posible debido al tratamiento que se hace de this. En ocasiones, como en el caso de los constructores, no lo es. Siempre que puedo defino las funciones tal que así:
```
const miFuncion = (a, b) => a * b;
```
Nombres de variables: Siempre uso Camel Case, aunque hasta hace no demasiado utilizaba Snake Case. Esto es un ejemplo de camelCase.
Nombres de clases: En este caso uso Pascal Case, tanto en el nombre de la clase como en el nombre del archivo que la incluye. Esto es un ejemplo de PascalCase.
Comillas simples o dobles: Siempre que pudo utilizo comillas simples en lugar de comillas dobles. Suelo reservar las comillas dobles para las etiquetas de atributos HTML, de modo que si tengo que insertar JavaScript en su interior, pueda hacerlo con comillas dobles. Aplico también este criterio con otros lenguajes de programación como PHP.
Plantillas Literales / Template Literals: Son las expresiones que usan comillas invertidas ` para definir cadenas. Siempre que tengo que insertar variables en cadenas de texto, utilizo estas comillas, insertando la variable en medio. En el siguiente tutorial puedes encontrar más información acerca de los template literals. Ejemplo: `Aquí estoy insertando una ${variable}` .
Nombres de funciones y métodos: Al igual que en el caso de las variables, utilizo Camel Case tanto para las funciones como para los métodos de las clases. Ejemplo: CamelCase.
Sentencias if: En este caso suelo utilizar dos variedades, ya que puedo situar las sentencias tanto en una como en varias líneas dependiendo de lo largas que sean:
```
// If normal
if (condicion) {
  // código
}

// If con un else
if (condicion) {
  // código
} else {
  // código
}

// If con varios else
if (condicion) {
  // código
} else if (condicion) {
  // código
} else {
  // código
}
```
En el caso de que las sentencias sean muy cortas, utilizo una sola línea. Esto es algo bastante criticado por algunos desarrolladores pero que a mi me resulta muy legible siempre y cuando las sentencias sean muy cortas, como cuando haces asignaciones a una variable. En cualquier otro caso utilizo varias líneas:
```
// If normal
if (sentencia) variable = true;

// If con un else
if (sentencia) variable = true;
else variable = false;
```
Sentencias switch: En este caso siempre defino una condición por defecto y también uso varias líneas:
```
switch (expresion) {
  case expression:
    // código
  default:
    // código
}
```
Bucles for: Siempre uso varias líneas. En este caso siempre inicializo el elemento que define las iteraciones del bucle en su propia definición. Considero que es mejor esto que insertarlo en la condición. Separo los diferentes elementos de la definición del bucle por un ;:
```
for (inicializacion; condicion; actualizacion) {
  // código
}
```
Bucles while: Siempre uso varias líneas:
```
while (condicion) {
  // código
}
```
Bucles do while: No es que suela utilizar demasiado este bucle. En varias líneas:
```
do {
  // código
} while (condicion);
```

Sentencias try/catch/finally: Así las defino:

// try catch
try {
  // código
} catch (error) {
  // código
}

// try catch finally
try {
  // código
} catch (error) {
  // código
} finally {
  // código
}

Escojas el estilo que escojas recuerda que lo importante es que seas constante y lo mantengas en todo tu proyecto. Y esto ha sido todo.