Capítulo 9. Linting con Ruffy pre-commit
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
En 1978, Stephen C. Johnson, investigador de los Laboratorios Bell, escribió un programa que podía detectar una serie de fallos y oscuridades en el código C. Bautizó el programa con el nombre de la pelusa de tu jersey cuando lo sacas de la lavadora: Pelusa. Se convertiría en el primero de una larga serie de linters, programas que analizan el código fuente y señalan las construcciones problemáticas.
Los Linters no ejecutan un programa para descubrir problemas con él; leen y analizan su código fuente. Este proceso se conoce como análisis estático, a diferencia del análisisen tiempo de ejecución (o dinámico). Esto hace que los linters sean rápidos y seguros: no tienen que preocuparse por los efectos secundarios, como las peticiones a los sistemas de producción. Las comprobaciones estáticas pueden ser inteligentes y también bastante completas: no necesitas dar con la combinación adecuada de casos de perímetro para desenterrar un fallo latente.
Nota
El análisis estático es potente, pero aun así debes escribir pruebas para tus programas. Mientras que las comprobaciones estáticas utilizan la deducción, las pruebas utilizan la observación. Los linters verifican un conjunto limitado de propiedades genéricas del código, mientras que las pruebas pueden validar que un programa satisface sus requisitos.
Los Linters también son excelentes ...
Get Herramientas Python hipermodernas now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
