Nuestro código debe ser lo más limpio y fácil de leer posible.
En realidad, ese es el arte de la programación: tomar una tarea compleja y codificarla de una manera que sea correcta y legible para los humanos. Un buen estilo de código ayuda enormemente a ello.
Aquí hay una hoja de trucos con algunas reglas sugeridas (consulte a continuación para obtener más detalles):
Ahora analicemos en detalle las reglas y sus razones.
No hay reglas de "debes"
Aquí nada está escrito en piedra. Éstas son preferencias de estilo, no dogmas religiosos.
En la mayoría de los proyectos de JavaScript, las llaves se escriben en estilo "egipcio" con la llave de apertura en la misma línea que la palabra clave correspondiente, no en una nueva línea. También debería haber un espacio antes del corchete de apertura, como este:
si (condición) {
// haz esto
// ...y eso
// ...y eso
} Una construcción de una sola línea, como if (condition) doSomething() , es un caso límite importante. ¿Deberíamos usar aparatos ortopédicos?
Aquí están las variantes anotadas para que pueda juzgar usted mismo su legibilidad:
? Los principiantes a veces hacen eso. ¡Malo! No se necesitan llaves:
if (n < 0) {alert(`La potencia ${n} no es compatible`);}? Dividir en una línea separada sin llaves. Nunca hagas eso, es fácil cometer un error al agregar nuevas líneas:
si (norte < 0)
alert(`La energía ${n} no es compatible`);? Una línea sin llaves (aceptable si es corta):
if (n < 0) alert(`La potencia ${n} no es compatible`);? La mejor variante:
si (norte < 0) {
alert(`La energía ${n} no es compatible`);
} 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.
A nadie le gusta leer una larga línea de código horizontal. Lo mejor es dividirlos.
Por ejemplo:
// comillas invertidas `permite dividir la cadena en varias líneas deja cadena = ` TC39 de ECMA International es un grupo de desarrolladores de JavaScript, implementadores, académicos y más, colaborando con la comunidad para mantener y evolucionar la definición de JavaScript. `;
Y, para declaraciones if :
si (
identificación === 123 &&
fase lunar === 'Gibbosa menguante' &&
Signo del zodíaco === 'Libra'
) {
letTheSorceryBegin();
}La longitud máxima de la línea debe acordarse a nivel de equipo. Suele tener 80 o 120 caracteres.
Hay dos tipos de sangrías:
Sangrías horizontales: 2 o 4 espacios.
Se realiza una sangría horizontal utilizando 2 o 4 espacios o el símbolo de tabulación horizontal (tecla Tabulador ). Cuál elegir es una vieja guerra santa. 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 que el símbolo de tabulación.
Por ejemplo, podemos alinear los parámetros con el corchete de apertura, así:
mostrar (parámetros,
alineado, // 5 espacios de relleno a la izquierda
uno,
después,
otro
) {
//...
}Sangrías verticales: líneas vacías para dividir el código en bloques lógicos.
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:
función poder(x, n) {
dejar resultado = 1;
// <--
para (sea i = 0; i < n; i++) {
resultado *= x;
}
// <--
resultado de devolución;
}Inserte una nueva línea adicional que ayude a que el código sea más legible. No debe haber más de nueve líneas de código sin sangría vertical.
Debe haber un punto y coma después de cada declaración, incluso si es posible omitirlo.
Hay idiomas en los que el punto y coma es realmente opcional y rara vez se utiliza. Sin embargo, 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. Vea más sobre eso en el capítulo Estructura del código.
Si es un programador experimentado en JavaScript, puede elegir un estilo de código sin punto y coma como StandardJS. De lo contrario, es mejor utilizar punto y coma para evitar posibles errores. La mayoría de los desarrolladores ponen punto y coma.
Intente evitar anidar código en demasiados niveles de profundidad.
Por ejemplo, en el bucle, a veces es una buena idea utilizar la directiva continue para evitar anidamientos adicionales.
Por ejemplo, en lugar de agregar un condicional if anidado como este:
para (sea i = 0; i < 10; i++) {
si (cont.) {
... // <- un nivel de anidamiento más
}
}Podemos escribir:
para (sea i = 0; i < 10; i++) {
si (!cond) continúa;
... // <- sin nivel de anidamiento adicional
} Se puede hacer algo similar con if/else y return .
Por ejemplo, dos construcciones siguientes son idénticas.
Opción 1:
función poder(x, n) {
si (norte < 0) {
alert("Negativo 'n' no admitido");
} demás {
dejar resultado = 1;
para (sea i = 0; i < n; i++) {
resultado *= x;
}
resultado de devolución;
}
}Opción 2:
función poder(x, n) {
si (norte < 0) {
alert("Negativo 'n' no admitido");
devolver;
}
dejar resultado = 1;
para (sea i = 0; i < n; i++) {
resultado *= x;
}
resultado de devolución;
} El segundo es más legible porque el “caso especial” de n < 0 se maneja desde el principio. Una vez realizada la verificación, podemos pasar al flujo de código "principal" sin necesidad de anidamiento adicional.
Si está escribiendo varias funciones "auxiliares" y el código que las utiliza, hay tres formas de organizar las funciones.
Declare las funciones encima del código que las usa:
// declaraciones de funciones
función crearElemento() {
...
}
función setHandler(elem) {
...
}
función paseo() {
...
}
// el código que los usa
dejar elem = crearElemento();
setHandler(elem);
caminar alrededor();Primero el código, luego las funciones.
// el código que utiliza las funciones
dejar elem = crearElemento();
setHandler(elem);
caminar alrededor();
// --- funciones auxiliares ---
función crearElemento() {
...
}
función setHandler(elem) {
...
}
función paseo() {
...
}Mixto: una función se declara donde se usa por primera vez.
La mayoría de las veces se prefiere la segunda variante.
Esto se debe a que al leer el código, primero queremos saber qué hace . Si el código va primero, quedará claro desde el principio. Entonces, tal vez no necesitemos leer las funciones en absoluto, especialmente si sus nombres describen lo que realmente hacen.
Una guía de estilo contiene reglas generales sobre “cómo escribir” código, por ejemplo, qué comillas usar, cuántos espacios sangrar, la longitud máxima de línea, etc. Muchas cosas menores.
Cuando todos los miembros de un equipo usan la misma guía de estilo, el código parece uniforme, independientemente de qué miembro del equipo lo escribió.
Por supuesto, un equipo siempre puede escribir su propia guía de estilo, pero normalmente no es necesario. Hay muchas guías existentes para elegir.
Algunas opciones populares:
Guía de estilo de JavaScript de Google
Guía de estilo de JavaScript de Airbnb
Idiomatic.JS
EstándarJS
(y muchos más)
Si es un desarrollador novato, comience con la hoja de referencia al principio de este capítulo. Luego podrás explorar otras guías de estilo para recoger más ideas y decidir cuál te gusta más.
Linters son herramientas que pueden verificar automáticamente el estilo de su código y hacer sugerencias de mejora.
Lo mejor de ellos es que la verificació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 utilizar un linter incluso si no desea ceñirse a un "estilo de código" en particular.
A continuación se muestran algunas herramientas de linting conocidas:
JSLint: uno de los primeros linters.
JSHint: más configuraciones que JSLint.
ESLint: probablemente el más nuevo.
Todos ellos pueden hacer el trabajo. El autor utiliza ESLint.
La mayoría de los linters están integrados con muchos editores populares: simplemente habilite el complemento en el editor y configure el estilo.
Por ejemplo, para ESLint deberías hacer lo siguiente:
Instale Node.js.
Instale ESLint con el comando npm install -g eslint (npm es un instalador de paquetes JavaScript).
Cree un archivo de configuración llamado .eslintrc en la raíz de su proyecto JavaScript (en la carpeta que contiene todos sus archivos).
Instale/habilite el complemento para su editor que se integra con ESLint. La mayoría de los editores tienen uno.
Aquí hay un ejemplo de un archivo .eslintrc :
{
"extiende": "eslint:recomendado",
"entorno": {
"navegador": verdadero,
"nodo": verdadero,
"es6": verdadero
},
"normas": {
"sin consola": 0,
"sangría": 2
}
} Aquí la directiva "extends" indica que la configuración se basa en el conjunto de configuraciones "eslint:recommended". Después de eso, especificamos el nuestro.
También es posible descargar conjuntos de reglas de estilo de la web y ampliarlos. Consulte https://eslint.org/docs/user-guide/getting-started para obtener más detalles sobre la instalación.
Además, ciertos IDE tienen linting incorporado, lo cual es conveniente pero no tan personalizable como ESLint.
Todas las reglas de sintaxis descritas en este capítulo (y en las guías de estilo a las que se hace referencia) tienen como objetivo aumentar la legibilidad de su código. Todos ellos son discutibles.
Cuando pensamos en escribir código "mejor", las preguntas que debemos hacernos son: "¿Qué hace que el código sea más legible y más fácil de entender?" y “¿Qué puede ayudarnos a evitar errores?” Estas son las cosas principales a tener en cuenta al elegir y debatir estilos de código.
Leer guías de estilo populares le permitirá mantenerse actualizado con las últimas ideas sobre tendencias de estilo de código y mejores prácticas.
importancia: 4
¿Qué hay de malo con el estilo del código siguiente?
función potencia(x,n)
{
dejar resultado=1;
for(let i=0;i<n;i++) {resultado*=x;}
resultado de devolución;
}
let x=prompt("x?",''), n=prompt("n?",'')
si (n<=0)
{
alert(`La potencia ${n} no es compatible, ingrese un número entero mayor que cero`);
}
demás
{
alerta(pow(x,n))
}Arreglalo.
Podrías observar lo siguiente:
función pow(x,n) // <- sin espacio entre argumentos
{ // <- corchete de figura en una línea separada
dejar resultado=1; // <- sin espacios antes o después =
for(let i=0;i<n;i++) {resultado*=x;} // <- sin espacios
// el contenido de {...} debe estar en una nueva línea
resultado de devolución;
}
let x=prompt("x?",''), n=prompt("n?",'') // <-- técnicamente posible,
// pero mejor que sean 2 líneas, además no faltan espacios;
if (n<=0) // <- no hay espacios dentro (n <= 0), y debe haber una línea adicional encima
{ // <- corchete de figura en una línea separada
// abajo: las líneas largas se pueden dividir en varias líneas para mejorar la legibilidad
alert(`La potencia ${n} no es compatible, ingrese un número entero mayor que cero`);
}
else // <- podría escribirlo en una sola línea como "} else {"
{
alert(pow(x,n)) // no hay espacios y faltan;
}La variante fija:
función poder(x, n) {
dejar resultado = 1;
para (sea i = 0; i < n; i++) {
resultado *= x;
}
resultado de devolución;
}
let x = rápido("x?", "");
let n = rápido("n?", "");
si (n <= 0) {
alert(`La potencia ${n} no es compatible,
ingrese un número entero mayor que cero`);
} demás {
alerta( pow(x, n) );
}