hace algún tiempo ayudé a un desarrollador junior, que tiene un problema aparente en su código, para averiguar qué estaba mal en él. Instaló una pelusa y descargó (Dios sabe por qué) un diccionario personalizado para ella. Preparé un pequeño entorno de prueba y le mostré la diferencia entre diferentes pruebas, en diferentes puntos y algunas limitaciones de cada uno (en este pequeño entorno).
hace poco estaba hablando de probar con un colega y recordé esta anécdota y me dije a mí mismo que escribiera un post sobre eso ya que podría ser interesante para muchos.,
¿qué es el linting?
Linting es la comprobación automática de su código fuente para detectar errores programáticos y estilísticos. Esto se hace utilizando una herramienta de pelusa (también conocida como linter). Una herramienta lint es un analizador de código estático básico.
el término linting proviene originalmente de una utilidad Unix para C. Hay muchos linters de código disponibles para varios lenguajes de programación hoy en día.
La programación de pelusa es un tipo de comprobación automatizada. Puede ocurrir al principio del desarrollo, antes de revisar y probar el código. Esto se debe a que las comprobaciones de código automatizadas hacen que los procesos de revisión y prueba de código sean más eficientes., Y liberan a tus desarrolladores para que se centren en las cosas correctas.
Muchas herramientas de prueba automatizadas aprovechan un linter incorporado para lanzar errores, establecer alguna puntuación sobre la calidad del código y bloquear la compilación o una etapa de implementación si esta puntuación es menor que la deseada (automáticamente o pausar el proceso lanzando una notificación para verificar manualmente si estos «errores» deben ser parcheados o no).
¿para qué está destinado?
Linting está destinado a reducir los errores y mejorar la calidad general del código de desarrollo, acelerar el desarrollo y reducir los costos al encontrar errores antes.,
¿cuándo usar el software Lint?
si esto es nuevo para usted, puede ser un poco exagerado con lints en este punto, pero no son una herramienta programática. Un lint es simplemente un script «scrapper» / lector de archivos con un archivo (generalmente un JSON o xml) con reglas predefinidas (o personalizadas) sobre cómo debe ser el código. De hecho, los IDE tienen una pelusa incorporada que le arrojará un error (es decir, si llama a un método inexistente, o si intenta agregar un valor de cadena a una variable entera) o una advertencia (es decir, si llama a un método inexistente, o si intenta agregar un valor de cadena a una variable entera)., si declara una variable dentro de un Condicional y luego devuelve esa variable al final de su método). Pero no estoy hablando de la pelusa de código incorporada, ya que estos linters son «suaves» y permisivos, de lo contrario muchas personas no usarán esos IDEs, veremos por qué más adelante.
Puede usar una pelusa específica si encaja en estas instrucciones:
Cuando usa lenguajes de programación interpretados.
algunos lenguajes son más adecuados para el linting de código que otros. PHP, Python y JavaScript son lenguajes interpretados, esto significa que carecen de una fase de compilación*., Por lo tanto, el uso del software lint es efectivo para garantizar un estilo de codificación consistente y resolver errores de codificación básicos en estos casos.
pero, cuando se trata de lenguajes compilados, como C y c++, usar software lint podría no ser suficiente. C y c++ son complejos y pueden requerir un análisis de código más avanzado.
*Usted puede estar gritando compilo JavaScript! pero de hecho, no es verdad. Hoy en día en front end estamos utilizando herramientas como bundlers, agregando algunas herramientas javascript que pasan nuestro js por algunas fases como minify, ugglify, ofuscate. Algunas de estas herramientas también eliminan el código no utilizado en su salida., Pero ninguna de estas cosas significa que está compilando javascript, ya que la salida será a .archivo js de todos modos; sin bytecode, sin ensamblador.es cierto que puedes convertir javascript en ensamblado web, pero no es una ruta directa de uno a otro; debes convertir tu js en algo «compilable» como el código C y luego compilarlo en ensamblado web.
Cuando se utilizan reglas estándar
Esta es una declaración un poco difícil., En un lenguaje de programación no podrá usar algo que no esté incorporado en su lenguaje de programación (eso no es cierto en absoluto, ya que puede agregar bibliotecas o lanzar comandos del sistema desde lenguajes de programación, pero de todos modos Lint no tiene nada que ver con eso…)
What Standard Rules stand for?
El uso de un marco se ajustará bien aquí, debe usar métodos integrados de marco para alcanzar la salida deseada.
A veces las reglas estándar significa código de moda., Estas metodologías y soluciones que la comunidad repite como un mantra hasta que encuentran otra manera a la moda de alcanzar el objetivo de una tarea determinada, o hasta que alguien con repercusión pública le dice a la comunidad «oye, estaba analizando estas soluciones y encuentro que hay una mejor manera de llegar a esto por estas razones» y luego la comunidad sigue adelante.
Cuando sus necesidades son básicas
Las herramientas de pelusa son excelentes para el análisis básico. Pero si necesita un análisis más sofisticado, debe buscar en otro lugar (Herramientas de prueba automatizadas y desarrollo basado en pruebas).
¿dónde debo ver una pelusa?
1., En pruebas automatizadas (las llamamos automatizadas porque se ejecutan automáticamente, pero alguien necesita codificar la prueba para cada caso de uso en una aplicación), como Cypress, puede agregar una pelusa para calificar la calidad del código.
esto puede ejecutarse en tiempo de desarrollo (cuando el desarrollador presiona el botón de prueba) o probablemente en la etapa de implementación. Por ejemplo, cuando envías algo a la rama master podría ser un disparador para subir las pruebas, incluyendo la pelusa, y bloquear el deploy (y culparte) si hiciste algo mal, entonces necesitarás reparar o encontrar el bug (esto no significa que sea tu culpa., Podría empujar una API que hace que su cliente se bloquee recibiendo valores inesperados, y esto será mi culpa, no la tuya).
estas pruebas no pretenden culparte, sino ayudar en el proceso de desarrollo, por lo general es mejor encontrar un error antes de integrarse en la etapa de preproducción debido a un fallo de prueba que encontrarlo por sorpresa en la producción.
2. En grandes proyectos, generalmente en grandes empresas., Si usted está en una empresa muy grande el gerente de proyecto debería como todo el código se vea como el mismo (formateo) por lo que probablemente tienen una pelusa para que en algún lugar que el punto si se añade 4 espacios en blanco para sangrar algo que quieren con 2 y que le culpará si usted no declaró un método con camel case por ejemplo.,
encuentro tonos de desarrolladores junior tratando de luchar contra eso porque les gusta algún formato particular, pero sin estas herramientas, estas grandes aplicaciones de software se verán como un monstruo de frankenstein en un futuro aumentando la dificultad en la lectura de todas las partes o siguiendo algunas rutas de método y anulaciones de clase. Piense en ello como leer un libro sobre dónde cada párrafo tiene un tamaño de fuente diferente, familia de fuentes y así.
¿dónde no usarlo?
este punto es muy fácil: no lo uses en contexto dinámico y en lenguajes que no sean de programación.
1. El primero es fácil de entender., Si estás en un contexto dinámico, la pelusa (un comprobador estático) nunca sabrá el resultado final y te culpará por las cosas que están bien, agregaré un ejemplo en el siguiente punto.
2. Esto debería sonar ridículo, redundante o puedes decirme «¿dónde usas una pelusa si no está en un lenguaje de programación?»
Mulder, hay linters HTML y CSS por ahí.
Sí.. um… Pero, ¿cómo?,
bueno, en realidad no son linters, solo son verificadores de código, lo mismo que puedes hacer con el validador w3c, sino que al copiar tu código en un validador, generalmente se ejecutan en tiempo de desarrollo culpándote de diferentes cosas basadas en la opinión de alguien, lo cual es molesto, inexacto y realmente no se ajusta hoy en día al uso de estas dos tecnologías (o tres si agregas SCSS), y lo más importante, generalmente no tienen una razón para cada afirmación, o las razones contradicen de un punto a otro, o la razón está desactualizada, o las razones no son aplicables a todos los proyectos., Es por eso que encontrará tonos de «Olvídese de CSSLint, es obstinado y no se ajusta a su proyecto» comentarios y muchos otros similares a través de internet.
Usted puede encontrar algunas piezas de código que se llama Pelusa por alguna razón, pero al menos que te digan «soy un obstinado código formateador» como esta .,
html lint podría ser útil a veces, ya que le obligará a agregar un atributo alt a las imágenes y otras prácticas de accesibilidad y Buenas (la mayoría de los IDE también le muestran una advertencia sin agregar una pelusa, que es mejor), pero esto no le impedirá usar un <span> como <p> u otro mal uso de HTML.
también le molestará si está escribiendo componentes de plantilla con declaraciones tontas como «no tiene declaración doctype, no tiene html, head, title ni body tag., Y podrías pensar «por supuesto, ya que este archivo se cargará dentro de un documento que ya tiene estas etiquetas», pero HTML lint no puede saberlo; los Lint son comprobadores estáticos y estás trabajando en un entorno dinámico, así que sigue adelante y elimina html lint en absoluto.
CSSLint es un poco diferente, no hay nada que puedas pelear aquí de todos modos, puedes escribir CSS válido o inválido, pero eso es todo.,
hay buenas prácticas en CSS que representan propósitos de eficiencia y velocidad (también se beneficiarán de UX), otros que irán para fines de mantenibilidad, escalabilidad y legibilidad (generalmente basados en la experiencia de Desarrollo), otros representan accesibilidad (basados en estudios de UI/UX y renderizados del navegador, pruebas de contraste de pantalla, etc.). Pero no tiene sentido combinarlo todo en un linter y decirle a los desarrolladores que igualen todas esas prácticas, en primer lugar porque hay contradicciones que necesitan un ser humano para tomar la decisión de usar una u otra.,
un caso de uso donde elegir podría tratarse por el hecho de que agregar todo el código CSS de accesibilidad aumentará observablemente el tamaño, el tiempo de carga y las métricas interactivas de la primera vez, por lo que generalmente elegirá solo las reglas de accesibilidad que mejor se adapten a sus clientes mientras mantiene un buen rendimiento.
para establecer un ejemplo tonto sobre una regla obstinada en el CSSLint digamos que quiero un gradiente lineal como fondo en mi bloque principal de la página de inicio. CSSLint lanzará una advertencia sobre el rendimiento de gradiente lineal.,
En este punto CSSLint quiere que elimine el gradiente lineal, pero ¿cuáles son las alternativas?
Usar una imagen será tonos de veces menos eficiente para alcanzar el diseño objetivo (y también reducirá la calidad visual del gradiente, y hará que sea más difícil cambiar el tamaño para adaptarse a todos los tamaños posibles del bloque). entonces, ¿qué podemos hacer? Simplemente ignore el CSSLint, porque es obstinado y esto no está respaldado por ninguna razón. hay una diferencia en Agregar un gradiente lineal vs agregar 42342 gradientes lineales en la misma vista., Por cierto, si los necesita, seguirá siendo más eficiente que el uso de imágenes.
también puede encontrar declaraciones contradictorias en él tales:
«no use IDs para el estilo». La razón es que será una regla no reutilizable.
Y
«No usar clases contiguas». No pude averiguar correctamente la razón sin leer la explicación de las reglas de css lint y la razón es «aunque técnicamente permitido en CSS, estos no son manejados correctamente por Internet Explorer 6 y anteriores».
tengo algo que decirte CSSLint., A nadie le importa IE 6 y anteriores, estamos en 2020, el 99% del software web es compatible con I. E. 11 tanto, que fue lanzado en 2013 por cierto y tiene menos de un 3% de uso.
por otro lado, donde por el amor de Dios se expresa que todas las reglas CSS tienen que ser reutilizables en la misma vista?
Si tiene un elemento único en su aplicación web, es decir, es probable que solo tenga una barra de navegación, solo una ventana emergente de chat si la hay, solo un logotipo de barra de navegación y solo un pie de página para nombrar algunos, ¿por qué necesita agregar su estilo global? ¿No es una práctica tan mala que es contraria a todos los otros idiomas en todo el mundo?,
como adición, digamos que tienes 5 vistas en tu proyecto. Si tienes un <nav> probablemente se mostrará en todos ellos, por lo que el mismo estilo que pones debajo #primary-navigation está funcionando en 5 vistas diferentes. ¿No es esta una forma de re-usabilidad?
para aumentar la tontería alrededor de que ambas reglas juntas, vea cómo le permite en una situación difícil.,
si no puede usar un id para el estilo <nav class="dark-theme">, y no puede agregar clases adyacentes<nav class="primary-navigation dark-theme">, ¿cómo se las arreglará para ampliar su estilo y hacerlo más fácil de mantener, legible por humanos y cómo lo administra para agregar escuchas de eventos de java-script cuando sea necesario de una manera eficiente?
simplemente no puedes.
¿Qué podríamos hacer semánticamente correcto y fácil de mantener?, Vamos a poner un ejemplo:
Aquí hay otra declaración que me hace reír por un tiempo:
Evite los selectores de atributos no calificados «los selectores de atributos no calificados, como , coinciden con todos los elementos primero y luego verifican sus atributos. Esto significa que los selectores de atributos no calificados tienen las mismas características de rendimiento que el selector universal (*)»
querida, esto no es diferente de lo que sucede cuando se usa el selector de clase, id o etiqueta.
las etapas del renderizado CSS del navegador son:
- construyendo el DOM., El DOM es una estructura de datos tipo árbol que contiene todos los nodos HTML de la página. Cada nodo contiene los datos sobre ese elemento HTML (como atributos, ids y clases) si el nodo tiene elementos HTML secundarios, también apuntará a esos nodos secundarios.
- construyendo el CSSOM. Cuando el navegador encuentra una hoja de estilo CSS (ya sea incrustada o externa), necesita analizar el texto en algo que pueda usar para diseños de estilo y pinturas. La estructura de datos en la que el navegador convierte CSS se denomina creativamente CSSOM.
- generando un árbol de renderizado., En resumen, el árbol de renderizado contiene toda la información necesaria para que el navegador cree píxeles en la página. El navegador básicamente toma el DOM y CSSOM y los aplasta juntos, eliminando cualquier cosa que no tenga un efecto en la salida renderizada.
- Diseño y pintura.
En la fase de diseño, el navegador calcula el tamaño y la posición de los elementos (aún no se ha renderizado) y luego, en el paso de pintura, comienza a generar píxeles que visualizaremos.,
como puede ver, Podría obtener un pequeño sesgo de rendimiento al anidar indiscriminadamente sus Selectores, como body>#main-content>.first-block .products-card p ya que generará nodos secundarios innecesarios en el CSSOM que necesitarán coincidir con el DOM y esto tomará un poco más de tiempo que usar simplemente un.products-card p, pero como necesitaremos mantener este código y probablemente escalarlo, debemos así que digamos #main-content .products-card p.
es una buena práctica, pero nunca he visto una aplicación web en la que los selectores más específicos están causando cuellos de botella de velocidad de carga., Esto generalmente es causado por iterar una y otra vez manteniendo tonos de código no utilizado que el navegador agregará a CSSOM y tendrá que comparar con DOM para averiguar si está bien agregarlo al árbol de renderizado o no.
por esta y otras muchas razones es por lo que puede encontrar artículos que explican cada punto equivocado en CSSLint como este que explican las cosas de una manera más extensa que yo aquí.
resumen
Los Linters son buenos para algunas cosas y malos para otras.,
También se pueden editar para adaptarse a algunas necesidades del proyecto o algunas preferencias de la empresa o persona para evitar estas reglas que son obstinadas y agregar otras reglas valiosas que se ajusten al proyecto en el que se encuentra.
Hay muchas razones para usar linters en lenguajes interpretados (en los compilados, el IDE y el compilador se encargarán de esto, pero también puede agregar una pelusa para verificar solo el formato del código o para obtener advertencias antes de compilar para evitar esperar hasta que el compilador encuentre un error o termine para saber si todo está bien).,
Hay pocas razones para agregar linters en HTML (creo que solo los propósitos de accesibilidad pueden ser útiles) y hay menos razones para agregar linters en CSS (que se pueden reducir a un verificador de formato de código).
¿has usado una pelusa? Si es así, dinos en qué idioma y contexto y cuál fue tu experiencia.
personalmente me gustó después de algunos ajustes al usar TypeScript.
Como siempre, espero que os guste este post y saludos,
Joel