Nuestro código debe ser lo más limpio y fácil de leer posible.

Ese es en realidad el arte de programar: tomar una tarea compleja y codificarla de una manera correcta y legible para el ser humano. Un buen estilo de código ayuda mucho en eso.

Sintaxis

Aquí hay una hoja de trucos con algunas reglas sugeridas (consulte a continuación para obtener más detalles):

Ahora vamos a discutir las reglas y las razones de ellas en detalle.

Llaves

En la mayoría de los proyectos de JavaScript, las llaves rizadas se escriben en estilo «egipcio» con la llave de apertura en la misma línea que la palabra clave correspondiente, no en una línea nueva. También debe haber un espacio antes del corchete de apertura, como este:

if (condition) { // do this // ...and that // ...and that}

de Una sola línea de construcción, tales como if (condition) doSomething(), es una ventaja importante caso. ¿Deberíamos usar aparatos ortopédicos?

Aquí están las variantes anotadas para que pueda juzgar su legibilidad por sí mismo:

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 línea

A nadie le gusta leer una larga línea horizontal de código. Es mejor dividirlos.

Por ejemplo:

// backtick quotes ` allow to split the string into multiple lineslet 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 de if estados de cuenta:

if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}

La longitud máxima de la línea debe ser acordado en el equipo de nivel. Suele ser de 80 o 120 caracteres.

Sangrías

Hay dos tipos de sangrías:

• Sangrías horizontales: 2 o 4 espacios.

  Una sangría horizontal se realiza utilizando 2 o 4 espacios o el símbolo de tabulación horizontal (tabulación de teclas). 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 pestañas es que los espacios permiten configuraciones de sangrías más flexibles que el símbolo de pestaña.

  Por ejemplo, podemos alinear los parámetros con el corchete de apertura, como este:

  show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}

• Vertical sangrías: 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 ejemplo siguiente, la inicialización de las 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;}

  Inserte una nueva línea adicional donde ayude a que el código sea más legible. No debe haber más de nueve líneas de código sin una sangría vertical.

  Punto y coma

  Un punto y coma debe estar presente después de cada instrucción, incluso si se puede omitir.

  Hay idiomas en los que un punto y coma es realmente opcional y rara vez se usa. En JavaScript, sin embargo, hay casos en los que un salto de línea no se interpreta como un punto y coma, dejando el código vulnerable a errores. Vea más sobre esto en el capítulo Estructura de código.

  Si eres un programador 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 trampas. La mayoría de los desarrolladores ponen punto y coma.

  Niveles de anidamiento

  Intente evitar que el código de anidamiento tenga demasiados niveles de profundidad.

  Por ejemplo, en el bucle, a veces es una buena idea usar la directiva continue para evitar anidamientos adicionales.

  Por ejemplo, en lugar de añadir un anidada if condicional como esto:

  for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}

  se puede escribir:

  for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}

  Una cosa similar puede hacerse con la etiqueta if/else y return.

  Por ejemplo, dos construcciones a continuación 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; }}

  la 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;}

  La segunda es más fácil de leer porque el «caso especial» de n < 0 se maneja el principio. Una vez finalizada la comprobación, podemos pasar al flujo de código «principal» sin necesidad de anidamiento adicional.

  Ubicación de funciones

  Si está escribiendo varias funciones «auxiliares» y el código que las usa, hay tres formas de organizar las funciones.

  La mayoría de las veces, se prefiere la segunda variante.

  Esto se debe a que al leer código, primero queremos saber qué hace. Si el código va primero, entonces se vuelve claro desde el principio. Entonces, tal vez no necesitemos leer las funciones en absoluto, 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 » 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 utilizan la misma guía de estilo, el código se ve uniforme, independientemente del miembro del equipo que 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.

  Algunas opciones populares:

  • Guía de estilo JavaScript de Google
  • Guía de estilo JavaScript de Airbnb
  • Idiomático.JS
  • StandardJS
  • (y muchos más)

  Si eres un desarrollador novato, comienza con la hoja de trucos al principio de este capítulo. Luego puedes buscar otras guías de estilo para recoger más ideas y decidir cuál te gusta más.

  Linters automatizados

  Linters son herramientas que pueden comprobar automáticamente el estilo de su código y hacer sugerencias de mejora.

  Lo bueno de ellos es que la comprobación de estilo también puede encontrar algunos errores, como errores tipográficos en los nombres de variables o funciones. Debido a esta característica, se recomienda usar un linter incluso si no desea atenerse a un «estilo de código»en particular.

  Aquí hay 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 debe hacer lo siguiente:

  1. Instalar nodo.js.
  2. Instale ESLint con el comando npm install -g eslint(npm es un instalador de paquetes JavaScript).
  3. Cree un archivo de configuración llamado .eslintrc en la raíz de su proyecto JavaScript (en la carpeta que contiene todos sus archivos).
  4. Instale / habilite el plugin para su editor que se integra con ESLint. La mayoría de los editores tienen uno.

  Este es 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" indica que la configuración se basa en la «eslint:se recomienda el» conjunto de valores de configuración. Después de eso, especificamos la nuestra.

  También es posible descargar conjuntos de reglas de estilo de la web y ampliarlos en su lugar. Consulte http://eslint.org/docs/user-guide/getting-started para obtener más detalles sobre la instalación.

  También algunos IDE tienen linting incorporado, que 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 a las que se hace referencia) tienen como objetivo aumentar la legibilidad del 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 principales cosas a tener en cuenta al elegir y debatir estilos de código.

  Leer guías de estilo populares le permitirá mantenerse al día con las últimas ideas sobre las tendencias de estilo de código y las mejores prácticas.