2009-07-17 6 views
10

¿Qué analizador de código estático (si lo hay) utiliza? He estado usando PyLint para Python y estoy bastante satisfecho con él, ahora necesito algo similar para el código C.Analizadores de código estático para C

¿Cuánto de su producción tiene que suprimir para el uso diario normal?

+0

Para ampliar mis preguntas: ¿Alguien ha usado SourceMonitor (http://www.campwoodsw.com/sourcemonitor.html), y cómo lo calificaría? – Josip

+1

¿Duplicado de http://stackoverflow.com/questions/2873/choosing-a-static-code-analysis-tool? –

Respuesta

14

Wikipedia tiene un list of static code analysis tools para varios idiomas (incluido C).

Personalmente, he usado tanto PC-Lint como Splint. La mejor opción depende del tipo de aplicación que haya escrito. Sin embargo, independientemente de la herramienta que utilice, habrá una baja relación señal/ruido hasta que ajuste correctamente la herramienta y su código.

PC-Lint es la herramienta más poderosa de Lint que utilicé. Si lo agrega a un proyecto existente, la relación señal/ruido puede ser baja. Sin embargo, una vez que la herramienta y su código están configurados correctamente, se pueden usar como parte de su proceso de compilación estándar. El último gran proyecto donde lo usé, lo configuramos para que las advertencias PC-Lint rompieran la compilación. Las licencias para PC-Lint cuestan $ 389, pero vale la pena el costo.

Splint es una gran herramienta de código abierto. Lo he usado en varios proyectos, pero descubrí que puede ser difícil de configurar cuando se usa un compilador con extensiones que no sean ANSI C (por ejemplo, en proyectos de sistemas integrados).

Valgrind también vale la pena considerarlo como una herramienta de análisis dinámica.


Usted específicamente solicitó su opinión sobre SourceMonitor. Esta herramienta proporciona métricas interesantes en su código, pero debe usarse como un complemento de la herramienta buena de Lint, ya que no proporciona ese tipo de análisis.

Como se indica en su página principal, se SourceMonitor:

... averiguar la cantidad de código que tiene y para identificar la complejidad relativa de sus módulos. Por ejemplo, puede usar SourceMonitor para identificar el código que es más probable que contenga los defectos y por lo tanto garantiza una revisión formal.

Lo usé en un proyecto reciente y lo encontré fácil de usar (incluso para el código de sistemas integrados). La métrica de complejidad es un recurso excelente para desarrollar código que será menos propenso a errores y más fácil de mantener.

SourceMonitor proporciona bonitos gráficos de su salida, así como XML bien formateados si desea automatizar la recolección de métricas. El único inconveniente es que la herramienta solo se ejecuta en Windows.

+0

Su opinión sobre Splint es realmente útil, porque estoy trabajando con el compilador Microchip C18 que admite pocas extensiones C. Gracias. – Josip

0

Utilicé PCLint por siempre y me gustó mucho. Me gustaría que entraran en C# ... Ellos son los que tienen los cuestionarios pop en C o C++ en todas las revistas.

3

Hay splint, aunque, para ser honesto, nunca he sido capaz de hacerlo funcionar; en mi plataforma, realmente es demasiado hiperactivo. En la práctica, mi más utilizado "pelusa" son las siguientes banderas de advertencia para gcc

-std=c89 -pedantic -W -Wall -Wstrict-prototypes -Wunreachable-code -Wwrite-strings -Wpointer-arith -Wbad-function-cast -Wcast-align -Wcast-qual 

Por supuesto, he olvidado la mayoría de lo que la mitad de ellos significan. Pero atrapan bastantes cosas.

+0

Existe una gran diferencia entre advertencias de pelusa y compilador porque pelusa cruza el módulo cruzado mientras que el compilador solo puede advertir sobre problemas en el archivo fuente compilado y los archivos de encabezado incluidos. – Dipstick

5

Utilizamos PC-Lint y están muy contentos con él.

Parece que hay un par de campos, en cuanto eliminación de mensajes y puesta a punto:

  • suprimen todo, entonces Desactivar supresión sólo lo que le interesa
  • todo lo Desactivar supresión, a continuación, Suprimir las advertencias de que no le interesan
  • mantener todo no suprimida

Tenemos la tendencia a caer en algún lugar entre la segunda y tercera categorías. Esto significa un ridículo volcado de texto de 100MiB + (un error por línea) por pelusa ejecutada en las bibliotecas principales (muchos códigos antiguos).

Una herramienta tipo diff personalizada busca cambios y los envía por correo electrónico al autor del compromiso, lo que mantiene la cantidad que la mayoría de la gente tiene que ver hasta unas pocas líneas. Recopilamos estadísticas interesantes sobre errores en el tiempo con algunos datos básicos de minería de datos.

Usted puede conseguir realmente pulido aquí, hiperenlaces los errores de nuevo a descripciones más detalladas, proporcionando "puntos" para la fijación de las advertencias existentes, etc ...

1

Soy un gran fan del trabajo de David Evans en LC/Lint, que aparentemente ha cambiado su nombre a Splint. Es muy agresivo y puede proporcionarle mucha información útil al agregar anotaciones a su código. Está diseñado para ser utilizado con las anotaciones del programador. Funcionará sin ellos, pero si tratas de usarlo como un simple inspector sin proporcionar ninguna anotación, probablemente te decepcionará. Si   lo que desea es una verificación totalmente automática, y si puede manejar una herramienta solo de Windows, es mejor que tenga PC-Lint de Gimpel. Jim Gimpel ha tenido clientes felices por más de 25   años.

Cuestiones relacionadas