¿Cuáles son los beneficios reales del análisis de código estático?

Se pueden usar herramientas como pc-lint o QAC para realizar análisis de código estático en una base de código.

En mi experiencia, el análisis estático a menudo produce una gran cantidad de ruido, es decir, advertencias sobre cosas que no son errores reales pero que de alguna manera violan una de las reglas en un conjunto de reglas dado. Desactivar ciertas reglas (ya sea para bien en el conjunto de reglas o mediante comentarios especiales en el código) puede ser un proceso realmente engorroso.

¿Cuáles son los beneficios reales del análisis de código estático?

Trabajé en un lugar que usaba un sistema comercial de análisis de código estático llamado Coverity Prevent, ¡y fue increíble! Es realmente sofisticado e inteligente.

Lanzamos alrededor de 18 GB de código C y C ++ de código abierto y propietario, y rastrearía a través de las rutas de código y rápidamente encontraría errores sutiles que le tomarían a un humano para siempre rastrear. También fue genial para señalar cosas que generalmente serían Heisenbugs.

Funcionaba cada pocos días contra nuestra base de código, y una buena característica era que podíamos decirle: "Esto no es realmente un error", y recordaría eso en el futuro.

El problema es que Coverity es realmente caro. No publican los costos, pero tengo la sensación de que para proyectos comerciales, comienza en cientos de miles de dólares por año. Pero probablemente nos ahorró tener que contratar a un montón de desarrolladores y personal de control de calidad, por lo que, en general, nuestra gerencia pareció pensar que era una buena compra.

Habiendo tenido esa experiencia, me veo favorablemente en el análisis de código estático.

Al comenzar con un nuevo idioma, es bueno tener un entrenador. Así es como pienso en las herramientas de análisis estático. Escribo mucho javascript y al principio aprendí algunos malos hábitos principalmente porque estaba transfiriendo algunas cosas de idiomas anteriores. Javascript es bastante flexible, por lo que puede salirse con la suya con casi cualquier cosa, pero si hubiera tenido jslint advirtiéndome sobre ciertos patrones, habría escogido mejores patrones de codificación desde el principio en lugar de tener que volver a aprender cosas más adelante.

Los analizadores estáticos son básicamente revisiones de código asistidas por máquina. Señalarán áreas cuestionables que podrían perderse durante las pruebas regulares.

Por ejemplo, ¿el autor realmente quiso hacer una tarea en este condicional?

if (x = 1) {
    ...
}

O tal vez un novato confunde el casting léxico:

char* number = "123";
int converted = number;

Ciertamente, los analizadores estáticos requieren ajustes. Por otra parte, el control de revisión, los wikis, los rastreadores de errores, las impresoras bonitas y otras herramientas también requieren cierta configuración. Cuanto más grande sea el proyecto, mejor será la recompensa por el trabajo inicial.

Desde la perspectiva de un consultor, cada herramienta de análisis estático tendrá algo de ruido, pero no todos los analizadores estáticos son iguales. Las herramientas de análisis estático como Coverity, Klocwork, Grammatech tienen buenas técnicas de análisis que deberían producir resultados más precisos. Si sintoniza y modifica un poco más, generalmente obtiene mejores resultados (después de todo, los analizadores estáticos deben poder ejecutarse en todos los diferentes tipos de código desde un pequeño dispositivo médico a un sistema operativo de red). La definición de "ruido" también depende de sus criterios para lo que constituye un informe digno de corrección. En un extremo del espectro, algunos desarrolladores marcan todos los informes que no arreglan como "falsos" (incluso el código mal escrito que no tienen tiempo para arreglar) y en el otro extremo,

Algunas de estas herramientas están más centradas en el análisis central y otras están más centradas en el escritorio, aunque las tres tienen características que admiten ambas. Como mencionó @Bob, cuestan dinero.

En mi empresa anterior, hemos utilizado el analizador estático de Parasoft. Y se creía dentro del equipo que al menos el 60% de los errores de tiempo de ejecución se detectaban antes de la compilación.

El análisis estático también se puede realizar sin herramientas, realizando revisiones manuales en el código del software. Esta suele ser la forma más rentable de mejorar la calidad del código.

La segunda mejor opción es invertir para una o más herramientas de análisis estático de alta gama (como Coverity, o KLOCwork). Dado que estas herramientas realizan análisis mucho más profundos que la pelusa, por ejemplo, la relación señal / ruido es mucho mejor.

Considero usar pelusa como la tercera opción, debido al alto nivel de ruido. Aplicar pelusa a un proyecto existente puede ser una tarea desalentadora.

En general, el análisis estático de programas ha progresado mucho en los últimos años. Las herramientas actuales de análisis estático son capaces de realizar análisis interprocediales profundos, y pueden identificar automáticamente, por ejemplo, condiciones previas y posteriores al procedimiento. Esto también puede ser de gran ayuda para revisiones de código posteriores.

Debido a la alta tasa de falsos positivos, no debe usar una herramienta de análisis estático (como lint o FindBugs) para cada compilación.

Más bien, es una buena comprobación de cordura consultar una vez que tiene un error y no puede resolverlo . En ese caso, puede entretener los falsos positivos, y es posible que ya haya reducido las posibles fuentes del error. Por ejemplo, si reproduce su error sin siquiera ejecutar algún módulo, puede ignorar lo que FindBugs dice para ellos. Esto es particularmente útil cuando está mirando un fragmento de código y cree que dice una cosa, mientras que el compilador lo lee literalmente (como en Java cuando tiene un equalsmétodo que toma el tipo de la clase en lugar de Object).

También puede hacer que las herramientas de análisis estático sean parte de su proceso de desarrollo: cuando un desarrollador obtiene una revisión de código, también debe ejecutar FindBugs en él. En resumen, es útil, pero no lo usará con tanta frecuencia como el compilador o el editor de texto.