Normas de codificación
Es fundamental que nuestro código sea claro y fácil de leer para los demás. Esto es esencialmente lo que implica la programación: tomar tareas complejas y escribirlas de manera clara y comprensible para las personas. Un estilo de codificación adecuado es crucial para lograr esto.
Reglas de sintaxis
A continuación, se presentan algunas pautas recomendadas (más detalles se encuentran al final):
Reglas y sus razones
No existen normas absolutas que se deban seguir sin excepciones. Estas son solo recomendaciones de estilo, no mandatos estrictos.
Llaves
En la mayoría de los proyectos de JavaScript, las llaves se escriben en estilo «K&R» (Kernighan y Ritchie), donde la llave de apertura se coloca en la misma línea que la declaración correspondiente, no en una nueva línea. Además, debe haber un espacio antes de la llave de apertura, como se muestra a continuación:
if (condition) {
// hacer esto
// ...y esto
// ...y esto
}
Una construcción de una sola línea, como if (condition) doSomething(), es un caso especial. ¿Deberíamos usar llaves aquí?
Aquí están las variantes anotadas para que puedas juzgar la legibilidad por ti mismo.
Los principiantes a veces hacen esto. ¡Es incorrecto! Las llaves no son necesarias:
if (n < 0) {alert(`Power ${n} is not supported`);}
Dividir en una línea separada sin llaves. Nunca hagas esto, es fácil cometer un error al agregar nuevas líneas:
if (n < 0)
alert(`Power ${n} is not supported`);
Una línea sin llaves: aceptable si es corta:
if (n < 0) alert(`Power ${n} is not supported`);
La mejor variante:
if (n < 0) {
alert(`Power ${n} is not supported`);
}
Para un código muy breve, se permite una línea, por ejemplo, if (cond) return null. Pero un bloque de código (la última variante) suele ser más legible.
Longitud de la línea
A nadie le gusta leer una línea horizontal de código demasiado larga. Es una buena práctica dividirlas.
Por ejemplo:
let str = `
ECMA International's TC39 is a group of JavaScript developers,
implementers, academics, and more, collaborating with the community
to maintain and evolve the definition of JavaScript.
`;
Y para sentencias if:
if (
id === 123 &&
moonPhase === 'Waning Gibbous' &&
zodiacSign === 'Libra'
) {
letTheSorceryBegin();
}
La longitud máxima de la línea debe acordarse con el equipo de trabajo. Suele ser de 80 o 120 caracteres.
Indentación
Hay dos tipos de indentación:
- Indentación horizontal: 2 o 4 espacios.
- Indentación vertical: líneas vacías para dividir código en bloques lógicos.
Se realiza una sangría horizontal utilizando 2 o 4 espacios o el símbolo de tabulación horizontal. Los espacios son más comunes hoy en día.
Una ventaja de los espacios sobre las tabulaciones es que los espacios permiten configuraciones de sangría más flexibles.
Por ejemplo, podemos alinear los argumentos con el paréntesis de apertura, así:
show(parameters,
aligned, // 5 espacios de relleno a la izquierda
one,
after,
another
) {
// ...
}
Incluso una sola función a menudo se puede dividir en bloques lógicos. En el siguiente ejemplo, la inicialización de variables, el bucle principal y la devolución del resultado se dividen verticalmente:
function pow(x, n) {
let result = 1;
for (let i = 0; i < n; i++) {
result *= x;
}
return result;
}
Debe insertarse una nueva línea extra donde ayude a hacer el código más legible. No debe haber más de nueve líneas de código sin una indentación vertical.
Punto y coma
Debe haber un punto y coma después de cada declaración, incluso si se puede omitir. En JavaScript, hay casos en los que un salto de línea no se interpreta como un punto y coma, lo que deja el código vulnerable a errores.
Si eres un programador de JavaScript experimentado, puedes elegir un estilo de código sin punto y coma como StandardJS. De lo contrario, es mejor usar punto y coma para evitar posibles errores.
Niveles de anidación
Intenta evitar anidar el código en demasiados niveles de profundidad. Algunas veces es buena idea usar la directiva continue en un bucle para evitar anidamiento extra.
Por ejemplo, en lugar de añadir un if anidado como este:
for (let i = 0; i < 10; i++) {
if (cond) {
... // <- un nivel más de anidamiento
}
}
Podemos escribir:
for (let i = 0; i < 10; i++) {
if (!cond) continue;
... // <- sin nivel extra de anidamiento
}
Algo similar se puede hacer con if/else y return.
Por ejemplo, las dos construcciones siguientes son idénticas.
Opción 1:
function pow(x, n) {
if (n < 0) {
alert("Negative 'n' not supported");
} else {
let result = 1;
for (let i = 0; i < n; i++) {
result *= x;
}
return result;
}
}
Opción 2:
function pow(x, n) {
if (n < 0) {
alert("Negative 'n' not supported");
return;
}
let result = 1;
for (let i = 0; i < n; i++) {
result *= x;
}
return result;
}
El segundo es más legible porque el “caso especial” de n < 0 se maneja desde el principio. Una vez que se realiza la verificación, podemos pasar al flujo de código “principal” sin la necesidad de anidamiento adicional.
Colocación de funciones
Si está escribiendo varias funciones “auxiliares” y el código que las usa, hay tres formas de organizar las funciones.
- Declare las funciones antes que el código que las usa:
// declaración de funciones
function createElement() {
...
}
function setHandler(elem) {
...
}
function walkAround() {
...
}
// el código que las usa
let elem = createElement();
setHandler(elem);
walkAround();
- Código primero, después funciones:
// El código que usa a las funciones
let elem = createElement();
setHandler(elem);
walkAround();
// --- Funciones auxiliares ---
function createElement() {
...
}
function setHandler(elem) {
...
}
function walkAround() {
...
}
- Mixto: una función es declarada donde se usa por primera vez.
La mayoría del tiempo, la segunda variante es preferida.
Eso es porque al leer el código, primero queremos saber qué hace. Si el código va primero, entonces queda claro desde el principio. Entonces, tal vez no necesitemos leer las funciones, especialmente si sus nombres son descriptivos de lo que realmente hacen.
Guías de estilo
Una guía de estilo contiene reglas generales sobre “cómo escribir” el código, qué comillas usar, cuántos espacios para indentar, la longitud máxima de la línea, etc. Muchas cosas menores.
Cuando todos los miembros de un equipo usan la misma guía de estilo, el código se ve uniforme, independientemente de qué miembro del equipo lo haya escrito.
Por supuesto, un equipo siempre puede escribir su propia guía de estilo, pero generalmente no es necesario. Hay muchas guías existentes para elegir.
Linters automatizados
Linters son herramientas que pueden verificar automáticamente el estilo de tu código y hacer sugerencias de mejora.
Lo mejor de ellos es que la comprobación de estilo también puede encontrar algunos errores, como errores tipográficos en nombres de variables o funciones. Debido a esta característica, se recomienda usar un linter incluso si no deseas apegarte a un “estilo de código” en particular.
Aquí hay algunas herramientas de linting conocidas:
- JSLint – uno de los primeros linters.
- JSHint – más ajustes que JSLint.
- ESLint – probablemente el más reciente.
Todos ellos pueden hacer el trabajo. El autor usa ESLint.
La mayoría de los linters están integradas con muchos editores populares: solo habilita el complemento en el editor y configura el estilo.
Por ejemplo, para ESLint debes hacer lo siguiente:
- Instala Node.JS.
- Instala ESLint con el comando
npm install -g eslint(npm es un instalador de paquetes de Javascript). - Crea un archivo de configuración llamado
.eslintrcen la raíz de tu proyecto de javascript (en la carpeta que contiene todos tus archivos). - Instala/Habilita el plugin para que tu editor se integre con ESLint. La mayoría de editores tienen uno.
Aquí un ejemplo de un archivo .eslintrc:
{
"extends": "eslint:recommended",
"env": {
"browser": true,
"node": true,
"es6": true
},
"rules": {
"no-console": 0,
"indent": 2
}
}
Aquí la directiva "extends" denota que la configuración se basa en el conjunto de configuraciones “eslint: recomendado”. Después de eso, especificamos el nuestro.
También es posible descargar conjuntos de reglas de estilo de la web y extenderlos. Consulta la documentación de ESLint para obtener más detalles sobre la instalación.
También algunos IDE tienen linting incorporado, lo cual es conveniente pero no tan personalizable como ESLint.
Resumen
Todas las reglas de sintaxis descritas en este capítulo (y en las guías de estilo mencionadas) tienen como objetivo aumentar la legibilidad de tu código. Todas ellas son discutibles.
Cuando pensamos en escribir un código “mejor”, las preguntas que debemos hacernos son: “¿Qué hace que el código sea más legible y fácil de entender?” y “¿Qué puede ayudarnos a evitar errores?” Estas son las principales cosas a tener en cuenta al elegir y debatir estilos de código.
La lectura de guías de estilo populares te permitirá mantenerte al día con las últimas ideas sobre las tendencias de estilo de código y las mejores prácticas.
