Análisis de código estático para Python
Hoy, escribimos mucho código y mucha gente está trabajando en el mismo proyecto que usted, lo que dificulta garantizar la calidad del código. Es entonces cuando aparece el análisis de código estático, también llamado linting, que encuentra fallas y vulnerabilidades de seguridad.
El análisis de código estático verifica su programa sin ejecutarlo. ¿No es agradable mientras estás codificando que Linter te advierte qué estás haciendo mal? Encontrar errores en un estado temprano aumentará el éxito en su programa. No significa que Linter nos dirá si el programa es correcto, tampoco garantizará una alta calidad del programa.
El primer análisis de código estático fue Lint en 1970, una herramienta para examinar los programas fuente de C que se habían compilado sin errores y para encontrar errores que habían escapado a la detección. Luego, otros lenguajes han lanzado sus propios Linters, por lo que aumentaron hasta llegar a ser tan populares hoy en día con muchas herramientas para diferentes lenguajes.
Beneficios de usar un Linting:
- Código limpio: leer el código será más fácil.
- Busca errores de sintaxis: no te pierdas ni un punto y coma.
- Proporciona una guía de estilo para seguir.
- Reciba notificaciones instantáneas de cada error.
- Ahorre tiempo.
Hay muchos Linters para cada idioma, esas herramientas tienen diferentes enfoques, algunos de ellos son especialistas en encontrar vulnerabilidades de seguridad y tipos específicos de errores, otros trabajos encuentran problemas de guía de estilo y mejoras en la calidad del código. por ejemplo, Python tiene lo siguiente:
- PyLint
- Pep8
- Flake8
- MyPy
- Pylama
- Bandit
- Coala
Los linters de python se basan en la documentación de PEP 8 (Propuestas de mejora de Python), específicamente sobre la guía de estilo para python.
Veamos algunos errores de tipo de código que podrían aparecer:
Errores:
En la siguiente imagen tenemos un ejemplo usando Pylint, que nos informa que se necesita paréntesis para la función de impresión.
WhiteSpace ( type 200):
Deberíamos terminar cada archivo con una línea.
Blank Lines (type 302):
Debemos tener 2 líneas en blanco antes de la declaración de clase
Imports (Type 400):
La importación debe estar en líneas separadas
Syntax Error (type 900):
Si tenemos errores de sangría, nuestro código no se ejecutará, es muy importante corregir este tipo de error.
Reducir errores es una de las principales prioridades cuando eres desarrollador, debes asegurarte de que tu código no tenga fallas. Escribir tests es una forma de evitarlo y el análisis de código estático también ayuda a lograrlo.
