Respirando aire en la guía de estilo JavaScript de AirBnB

Nadie se propone escribir código feo y con un estilo incoherente. Simplemente sucede.

Incluso como el único desarrollador en un proyecto, cuanto más tiempo pasa y más código genera, más difícil se vuelve mantener un estilo de código consistente.

Por eso necesitas una guía de estilo.

He experimentado de primera mano cuánto más pueden lograr los equipos después de adoptar una guía de estilo.

Ya no necesita hacer pequeñas decisiones de estilo a lo largo del día. Basta con consultar la guía de estilo.

Y cuando un compañero de equipo necesita mantener su código, es un código limpio que pueden leer y comprender.

Adoptar una guía de estilo es una de las cosas más fáciles que puede hacer para mejorar la capacidad de mantenimiento de su código, lo que en última instancia aumenta la productividad de su equipo. Entonces, exploremos la forma más popular de hacer esto.

Ingrese AirBnB + ESLint

El ecosistema de JavaScript ofrece una amplia variedad de herramientas y guías de estilo. Esto no debería sorprender a nadie. con JavaScript, esperamos una amplia variedad de todo.

Pero a medida que el ecosistema madura, los desarrolladores experimentados comienzan a anhelar "la forma estándar" de hacer las cosas que ofrecen los ecosistemas más solidificados.

Por supuesto, puede pasar unos días explorando el ecosistema de JavaScript y comparando diferentes herramientas, pero intentaré ahorrarle algo de tiempo : ESLint es la herramienta de linting de JavaScript más popular y la guía de estilo de AirBnB es la más utilizada. guía de estilo.

Para obtener más detalles sobre cómo agregar ESLint a su proyecto, consulte este enlace.

Una vez que lo haya resuelto, puede configurar su proyecto para hacer cumplir la guía de estilo de AirBnB instalando su paquete npm:

npm install --save-dev eslint-config-airbnb

Agregue la siguiente línea en su archivo .eslintrc

"extends": "airbnb"

¡Y voilá! Su código ahora está sujeto a las reglas de la guía de estilo de JavaScript más popular. ¡Feliz codificación!

Los estándares están sobrevalorados

Si bien estoy de acuerdo con la mayoría de las reglas de la guía de estilo, aquí hay una lista de anulaciones que compilé. Así es como se ven los archivos .eslintrc en las carpetas raíz de los proyectos:

Permítanme explicar en detalle el razonamiento detrás de cada una de estas personalizaciones.

Sangría

La guerra de pestañas VS espacios potencialmente puede arruinar las amistades y posiblemente incluso sabotear las relaciones románticas.

Prefiero sangrar los espacios de mi código 4, aunque la gran mayoría de las configuraciones prefieren una sangría de 2.

Mi razonamiento es que para escribir código limpio, las sangrías más grandes le brindan una mejor representación visual de cuán profundo es el anidamiento en sus funciones y cuántas ramas diferentes tiene.

Definitivamente no debería anidar código más profundo que 3 o 4 capas dentro de un archivo JavaScript (es un olor a código). Por lo tanto, tener 4 espacios le ofrece una mejor legibilidad, al tiempo que conserva otras reglas, como mantener su código dentro de un límite de 80 o 120 caracteres por línea.

Además, la sangría es una de las reglas que da más "aire" a la guía de estilo predeterminada de AirBnB. Como resultado, su código no se amontona tanto en el lado izquierdo del editor.

Espaciado

Esta es probablemente la mayor desviación del estándar. Odio el código abarrotado. Empecé a escribir código con relleno de espacio extra hace más de 2 años y nunca miré hacia atrás.

Entonces, ¿qué significan esas reglas? Bueno, eche un vistazo al siguiente código. Técnicamente, respeta las reglas de la guía de estilo oficial de AirBnB.

Lo sé, es un poco confuso. Intenté buscar una función de complejidad media en una de mis bases de código, pero tuve que ofuscar mucho, así que no trates de entender la lógica detrás del código (porque no hay ninguna). Intenta leerlo. Intente centrarse, por ejemplo, en las variables que se utilizan en varios lugares, cuando los parámetros se pasan a las funciones y dónde están las llamadas a las funciones.

Ahora eche un vistazo al mismo código, pero con las reglas de espaciado adicionales aplicadas:

No estoy diciendo que sea muy legible ahora, pero puede identificar más fácilmente dónde tiene los parámetros enviados a las funciones, especialmente alrededor de las funciones curry.

También verifique la diferencia entre la sangría de 2 y 4 espacios en los dos ejemplos.

Al principio, estas técnicas pueden no parecer una gran mejora. Te animo a que los pruebes. Creo que rápidamente experimentará la diferencia que esto hace.

Citar guerras

Si bien las dos primeras categorías tenían algunos argumentos claros, debo decir que la decisión de las comillas simples frente a las dobles es muy subjetiva.

Mi preferencia por las comillas dobles probablemente proviene de trabajar mucho con React, donde mezcla JavaScript con etiquetas JSX. Dado que JSX está más cerca de HTML, la tendencia es agregar atributos entre comillas dobles. Entonces comencé a usar comillas dobles para todo, solo por coherencia.

Una cosa que he notado es que es mucho más probable que necesites escribir una comilla simple dentro de una cadena de texto en inglés que una comilla doble (“Estoy aquí”, “No hagas eso”). Entonces, las comillas dobles pueden ser más convenientes en estos casos.

Disposición del código

La guía de estilo oficial de AirBnB tiene una regla de "no usar antes de definir", que arroja un error si intenta usar algo antes de definirlo. Esta es una buena regla, especialmente para las variables, porque no debe depender del izado y debe tener en cuenta el problema de la zona muerta temporal cuando utilice let y const.

Prefiero permitir que las funciones se utilicen antes de que se definan. La razón es simple: la mayoría de las veces, dividirá sus funciones en subfunciones más pequeñas. Sin embargo, la regla "no usar antes de definir" le indicará que coloque estas subfunciones antes de la función original.

Pero sus subfunciones están ahí para abstraer partes del algoritmo. No deberían molestarle cuando abre un archivo que contiene su función de nivel superior , que utiliza fuera del archivo.

Por supuesto, esto es discutible. Pero sí afecta la depuración. Cuando itera sobre algún código y encuentra una llamada a una función diferente, idealmente debería poder mirar debajo de ella o, en el peor de los casos, desplazarse hacia abajo a través de algunas subfunciones y encontrar lo que está buscando.

Esto, en combinación con la declaración de función de AirBnB contra la expresión de funciónregla,puede darle la libertad de estructurar sus módulos o bibliotecas de funciones como desee, mientras se asegura de no llamar accidentalmente a una función no inicializada.

Const sobre dejar

Aquí hay otra pequeña desviación de la guía de estilo. Puedes notar en mi configuración:

"prefer-const": 1

En la configuración de AirBnB, esto se establece en 2, que significa error , mientras que 1 significa advertencia .

Ahora, si no entiende por qué debería preferir const a let, puede leer más sobre esto aquí y aquí.

En cuanto a mi desviación, prefiero una advertencia, porque hay situaciones en las que no cambias la asignación de una variable, pero cambias mucho su contenido.

Eche un vistazo a este código:

Las reglas le dirán que esto es correcto: el hash debe ser constante porque no se reasigna. Pero esto nunca tuvo sentido para mí. Debo ser consciente de que se están produciendo muchos cambios dentro del hash.

Entonces usaré let para señalar el hecho de que la variable está sujeta a cambios. const y let deberían dar más significado a sus variables y no deberían ocultar la verdad de ninguna manera.

Complejidad del código

Puede la complejidad del código ciclomático para calcular la complejidad de cada una de sus funciones.

Decidir el nivel máximo de complejidad es complicado. Idealmente, debería ser lo más bajo posible, lo que significa que sus funciones deberían tener como máximo 1 o 2 posibilidades de ramificación.

Tiene sentido tener ese número lo más bajo posible desde la perspectiva de la reutilización y prueba del código. Pero hay momentos en los que es más difícil descomponer las funciones. Es por eso que veo la complejidad más como una advertencia que como un error.

Lo importante aquí es limitar el número de funciones que alcanzan ese límite máximo de complejidad. Incluso en una base de código de tamaño mediano, no me gustaría ver más de 10 funciones que rompan esta regla. Así que elegí el valor máximo de 5 para resaltar esas funciones. Apuntaré a estas funciones cuando tenga tiempo para refactorizar.

La complejidad se puede resolver de múltiples formas. La refactorización en funciones más pequeñas es la más obvia. Otra opción es transformar sus declaraciones de conmutación en asignaciones de mapeo.

Tuvimos varios debates dentro de nuestro equipo y terminamos usando 5 como valor de referencia para la regla de máxima complejidad. Pero en algunos casos bajamos a 4, solo para asegurarnos de que estamos escribiendo código limpio y simple.

Una nota sobre React

Debido a que trabajo mucho con React, y la configuración de AirBnB también contiene una gran cantidad de reglas en esa área, también quería incluir algunas de mis preferencias aquí.

El objetivo principal de mis anulaciones de React es limitar la diferenciación entre los módulos regulares de JavaScript y los componentes de React, así como entre el código JavaScript y JSX. Es por eso que elijo una sangría similar y el uso de comillas dobles para todos los atributos JSX. Y es por eso que prefiero dejar todos mis archivos con la extensión .js.

Finalmente, en relación con los componentes de clase frente a los de fábrica, tiendo a preferir los últimos. No veo ninguna ventaja en usar clases en este momento. Puedo escribir una publicación futura ampliando por qué me siento así.

¡Eso es todo! Espero que hayas disfrutado leyendo esto. Agradezco sus comentarios a continuación.

Si le gustó el artículo, haga clic en el corazón verde a continuación, y sabré que mis esfuerzos no son en vano.