Más y más equipos han adoptado pelusa y otros estática de las herramientas en su proceso de desarrollo. Algunos los integraron en el IDE de su preferencia, otros los automatizaron ejecutándolos como un paso adicional en su CI. Además, algunos corren en ambos sentidos.
¿Qué es un linter, entonces?
según Wikipedia, linter
es una herramienta que analiza el código fuente para marcar errores de programación, bugs, errores estilísticos y construcciones sospechosas.,
El primer linter fue escrito por Stephen C. Johnson en 1978 mientras trabajaba en el sistema operativo Unix en Bell Labs. Después de eso, muchos otros linters han aparecido para diferentes propósitos y lenguajes, no solo C.
los primeros linters utilizados para verificar el código fuente y encontrar optimizaciones potenciales para los compiladores. Pero, a lo largo de los años, muchos otros controles y análisis se incluirían en el proceso de linting.
el uso de linters también ha ayudado a muchos desarrolladores a escribir mejor código para lenguajes de programación no compilados., Como no hay errores de tiempo de compilación, encontrar errores tipográficos, errores de sintaxis, usos de variables no declaradas, llamadas a funciones indefinidas o obsoletas, por ejemplo, ayudar a los desarrolladores a solucionarlo más rápido y reducir los errores antes de la ejecución.
Borra han evolucionado
Borra han evolucionado. Comenzaron con esos simples controles, pero hoy en día, se están volviendo más y más sofisticados. Realizan análisis estáticos, aplican indicadores de configuración, verifican el cumplimiento de una guía de estilo o regla de seguridad determinada y mucho más.,
exploremos algunas de estas comprobaciones y cómo pueden ser útiles para usted.
análisis estático
análisis estático significa que el software automatizado se ejecuta a través de su fuente de código sin ejecutarlo. Comprueba estáticamente posibles errores, fugas de memoria y cualquier otra comprobación que pueda ser útil.
Si eres un desarrollador de Python, es posible que ya conozcas Radon. Puede contar las líneas de código fuente (SLOC), líneas de comentarios, una línea en blanco y otras métricas sin procesar, pero también puede calcular un «índice de mantenibilidad», que puede ser muy importante en algunos proyectos.
eso es solo un ejemplo., Hay muchos otros linters que realizan comprobaciones de análisis estático.
libro electrónico gratuito: haga clic aquí para descargar las solicitudes de revisión y extracción de código de decodificación de libro electrónico gratuito. Obtenga todos los puntos clave y las mejores prácticas para implementar una cultura de revisión de código.
Código de estandarización
De https://xkcd.com/1285/
la Normalización de su código es una gran manera de mover la conversación más productiva de nivel., Tener una guía y ejecutar linters contra la base de código evita cambios estéticos en su solicitud de extracción, como reemplazar todas las pestañas por espacios, sangrar una asignación variable o incluso saltos de línea después de un número determinado de caracteres.
maximizar cambios significativos lleva su discusión a temas que importan, como decisiones arquitectónicas, problemas de seguridad o errores potenciales.
Por cierto, los problemas de seguridad y errores potenciales también se pueden evitar por linters!
problemas de seguridad
Si te gustan los Rails, probablemente hayas oído hablar de Brakeman., Es una herramienta de seguridad de análisis estático. Es beneficioso encontrar posibles problemas de seguridad. Por ejemplo, ejecuta comprobaciones en busca de inyección SQL cuando utiliza el #find_or_create_by
de ActiveRecord y sus amigos. También agrega comprobaciones para XSS, opciones de configuración y mucho más.
Ruby no es el único lenguaje con este tipo de motor. SourceLevel soporta muchos motores para diferentes idiomas. Brakeman incluido.
errores potenciales
JavaScript tiene algunos trucos. Uno de los más famosos es la diferencia entre ==
y ===
., Es una buena práctica, y evita mucho tiempo de depuración, usar siempre ===
. Si habilita, por ejemplo, ESLint para verificar eso, puede decirle qué parte de su código está usando ==
e incluso reemplazarlo por usted.
mejoras de rendimiento
cada desarrollador experimentado sabe no solo la importancia de realizar software, sino muchos trucos que lo mejoran. El problema es: ¿qué pasa con los recién llegados? ¿Cómo puedes transmitir este conocimiento? Incluso los programadores mayores pueden perder una técnica o dos. Entonces, ¿por qué no dejar que un software de automatización lo haga por usted?,
¿sabías que en CSS, el selector universal (*) puede ralentizar el tiempo de carga de una página? ¿O que los selectores de atributos no calificados tienen las mismas características de rendimiento que el selector universal? Evitarlos es una buena práctica.
muchos linters incluyen una comprobación de rendimiento. Pueden agregar diferentes tipos de mejoras de rendimiento para desarrolladores experimentados y recién llegados. CSSLint es solo un ejemplo.
Y muchos otros aspectos
Hasta el infinito y más allá!, Hay montones y montones de linters para diferentes lenguajes de programación, archivos de configuración e incluso para integraciones de software. Cualquier control que importa y puede ser automatizado puede convertirse en un linter.
si trabajas en un escenario en particular, es posible que tengas que escribir tu linter, aunque no es demasiado probable en nuestra industria. Comprueba las características de accesibilidad de HTML, Los errores potenciales de internalización, los errores gramaticales y muchos otros ya están ahí, de código abierto, esperando que descargue, configure y comience a usar.
beneficios del linting
según Ferit T.,, linting mejora la legibilidad, elimina errores tontos antes de la ejecución y la revisión del código. Pero, como se mencionó, linting puede hacer trabajos más complejos, como detectar olores de código o realizar análisis estáticos de su base de código.
pero, en la práctica, ¿cuáles son las ventajas de linting?
mejora el nivel de discusión de revisión de código
si su Pull Request no tiene errores tipográficos, ni variables no utilizadas, y cumple con la guía de estilo, la conversación tiende a centrarse en el punto de vista de la arquitectura. Eso es., Pull Request es un excelente lugar para señalar problemas de rendimiento, vulnerabilidades de valores o sugerir mejores abstracciones. No necesitas entrar en esa discusión entre comillas simples o dobles o tabulaciones vs espacios. Es un aumento de productividad seguro.
hace que el código parezca escrito por una sola persona
a medio y largo plazo tener una base de código confiable que parezca escrita por la misma persona es excelente. La mantenibilidad y la evolución son más fáciles porque todo el mundo tiende a entender lo que se escribe más rápido y más preciso., Evita errores, hace que el trabajo sea más agradable para los desarrolladores y acelera el tiempo de comercialización de nuevas características.
da visibilidad de la salud de su base de código
¿Está su código saludable? No lo sabrás hasta que lo midas. Una forma emocionante de hacerlo es agregar un paso en su canalización de CI/CD para medir la evolución del Estado de salud de su código. Mejor que eso, puede tomar medidas tan pronto como sea posible cuando vea que su salud se descompone., Tales acciones pueden implicar la creación de tarjetas de débito técnicas en su Junta Directiva o incluso plantear el problema durante su retrospectiva ágil o reunión del Comité de arquitectura.
difunde el conocimiento y la propiedad sobre la calidad del código
los desarrolladores experimentados pueden analizar una diferencia y plantear cuestiones relevantes sobre el cambio propuesto. Probablemente saben dónde Buscar: ¿son descriptivos los nombres de las variables? ¿Cuántas líneas toma un método? Hay alguna superclase?
Pero ¿qué hay de los recién llegados? El conocimiento en un equipo es a menudo heterogéneo. Significa que no todos los desarrolladores saben qué revisar el código., Tener un linter para decir dónde están los olores de código automáticamente es una excelente manera de difundir este conocimiento y hacer que el equipo sea responsable de los cambios.
La calidad no es una responsabilidad individual. Es esencial medir y controlar la calidad del código a lo largo del tiempo. De lo contrario, el código se vuelve desordenado, lo que ralentiza el desarrollo y el tiempo de comercialización.,
Controla las deudas técnicas
como muchos linters modernos buscan posibles deudas técnicas, como olores de código, desajustes de guías de estilo o código mal diseñado (cadenas profundas de declaraciones if
, o métodos demasiado complejos, por ejemplo), linters se correlaciona con la deuda técnica.
hacer explícitas las deudas técnicas durante el proceso de revisión de código ayuda a los desarrolladores o ingenieros de software a detectar, discutir y corregir antes de la fusión en la rama master
. Es una práctica muy conveniente que controla las inserciones de deuda técnica.,
Automatice su revisión de código: SourceLevel admite + 30 linters para ayudarlo a mejorar la calidad del código. Haga clic aquí para ver una demostración o iniciar una prueba gratuita.
Ejemplos de pelusa
Hay una gran cantidad de pelusa por ahí. Dependiendo del lenguaje de programación, hay incluso más de un linters para cada trabajo. Por ejemplo, para el lenguaje de programación Go, hay ktlint y detekt. Ambos realizan un trabajo similar. Lo mismo sucede con eslint, un linter diseñado para JavaScript. Funciona muy similar a tslint o jshint.,
Borra centra en la Seguridad
- Guardafrenos para Ruby
- Bandido para Python
- Nodo de Seguridad para JavaScript
Borra centrado en la guía de estilo y convenciones de codificación
- CSSLint., SCSS Lint and SASS Lint for Cascading Style Sheet
- Gofmt for Go language
- Swiftlint for Switft
- rustfmt for Rust
- Credo for Elixir
Linters for Static Analysis
- pep8 for Python
- Phan or PHP Mess Detector for PHP
- kibit for Clojure, ClojureScript, cljx, y otras variantes de Clojure.
- PMD for Java
conclusión
Los Linters le ayudan a ser más productivo y le ahorran tiempo y dinero. Impulsan a su equipo a tomar mejores decisiones (las orientadas por los datos) y comparten la propiedad sobre la calidad.,
en SourceLevel, admitimos muchos linters. Se ejecutan contra cada solicitud de extracción abierta y comentan en la línea adecuada y archivan los problemas encontrados. Aumenta la productividad y la eficacia de los desarrolladores.
lo llamamos automatización de revisión de código. Cada repositorio puede tener su archivo de configuración y luego revisar las solicitudes de extracción de acuerdo con las reglas de guía de estilo elegidas.