2008-10-15 26 views
11

tuve un error desagradable que desperdicia mi tiempo y el de mi colega, que era algo así:¿Alguna herramienta para detectar errores tontos en el código C?

for (i = 0; i < blah; i++); // <- I had a semi-colon here, that's the bug! 
{ 
    // Some awesome logic here 
} 

En primer lugar, es muy embarazoso, segunda cosa, que nunca debería repetir esto. Soy relativamente nuevo en C. En Java, creo que puedo usar FindBugs para detectar errores como estos, ¿qué herramienta debo usar para el código C? ¿Hilas?

+3

Hemos tenido un gran éxito con el uso de un bate de béisbol aquí. Después de detectar el primer error tonto, ¡tienden a no hacer otro! – Danimal

+0

Ah, el problema del punto y coma es un problema recurrente. Una extra, una faltante; no hace ninguna diferencia. Todos conducen a la misma búsqueda del dolor en el culo que lleva una eternidad y resulta en "¡Do!" y una bofetada en la cabeza. Todavía lo tengo de vez en cuando. –

+0

Es posible que desee especificar la plataforma. No todas las herramientas funcionarán sin cambios en todas las plataformas. –

Respuesta

15

Sí, PC-Lint es probablemente la mejor herramienta disponible.

+1

Pero prepárese para un * lote * de advertencias si la base de código tiene algún tipo de tamaño y no se ha impreso ya. –

+1

Es cierto acerca de muchas advertencias, pero todas son configurables individualmente. Entonces puedes apagar todo lo que necesites. –

+0

Encuentro que las advertencias de PC-lint son crípticas y poco claras en el mejor de los casos. –

3

Comenzaría aprendiendo sobre splint y gdb. Si necesita más avanzado, construya sobre estas dos herramientas. Pero son un buen comienzo.

7

Además de Lykathea's PC-Lint suggestion, también puede obtener mejores (o al menos más) diagnósticos si aumenta el nivel de advertencia del compilador. Algo así como /W4 o -Wall

Aunque no estoy seguro de si su problema en particular hubiera quedado atrapado con esto (MS VC no parece marcarlo incluso con todas las advertencias habilitadas). Creo que es porque no es una expresión poco común que los bucles for estén vacíos cuando el trabajo se realiza como efectos secundarios de las expresiones de control de bucle.

0

Cualquier buen entorno de programación GUI ("IDE" - Integrated Development Environment) como Eclipse generaría una advertencia en un caso como ese.

4

Un par de cosas que me han salvado en el pasado, desde la parte superior de mi cabeza:

  • uso si (3 == bla) en lugar de (bla == 3), porque si usted escribe mal y escriba (3 = bla) el compilador se quejará.

  • Utilice all-warnings interruptor. Tu compilador debería advertirte sobre declaraciones vacías como esa.

  • Use assertions cuando pueda y programe a la defensiva. Haga un buen esfuerzo para que su programa falle temprano, verá las debilidades de esa manera.

  • No intente eludir las salvaguardas que el compilador o el sistema operativo hayan implementado. Ellos están ahí para su facilidad de programación también.

+3

No me gusta la convención '(CONST == var)'. Hace que el código sea mucho menos legible. Una herramienta de análisis estático se asegurará de que nunca escriba '(var = CONST)'. –

-1

En este (antiguo) versión de How to Shoot Yourself In the Foot, y en muchas otras versiones en la web, C es siempre el lenguaje que permite el procedimiento más simple. Cuando programe en C, debe recordar esto y tener cuidado. Si quieres protección, elige otro idioma.

Este refrán es attributed al propio Bjarne Stroustrup (C++). A (des) cita:

"C hace que sea fácil de disparar en el pie"

+1

la cita que escuché fue "C hace que te sea fácil disparar en el pie, pero con C++ te deja sin piernas" –

+0

Steven A. Lowe, tienes razón; mira el enlace de Stroustrup. Es por eso que escribí "(mis) comillas". – gimel

0

Un buen marcador de resaltado de sintaxis hará algunos casos como éste más visible.

+0

O un reformateador como sangría de GNU. – reinierpost

2

GCC tiene la mayor parte de la funcionalidad que Lint ha incorporado a través del warning flags.

+0

No se olvide de -O2. –

0

Sugeriría ver si tiene la capacidad de enforce MISRA standards. Fueron escritos con gran pensamiento y muchas reglas que son simples de verificar para un compilador. Por ejemplo, una regla que uso requiere que todos los comandos NOP tengan su propia línea. Esto significa cuando pones un; al final de una declaración de bucle, se producirá un error al decir que no está en su propia línea.

0

QA·C por Research programación es otra buena herramienta de análisis estático para C.

Cuestiones relacionadas