¿Cuál es la mejor herramienta de línea de comandos para limpiar el código?

Cuando escribo código C, solo uso un editor y gcc. Me preguntaba si alguien podría sugerir una herramienta buena y simple que encuentre variables no utilizadas, declaraciones de funciones y posiblemente realice algunas optimizaciones.

¿Alguien sabe una buena herramienta?

Como señaló Dan Fego, GCC puede detectar variables no utilizadas y funciones estáticas no utilizadas. Normalmente, no encontrará funciones externas que no se utilicen, ya que normalmente funciona con un archivo de origen a la vez.

GCC (v4.3.2) tiene cientos, si no miles de opciones. Uno que podría ayudar es ‘ --combine ‘ para combinar archivos de origen (siempre y cuando no tenga la costumbre de poner la misma función o nombres de variables dentro de diferentes archivos de origen).

La opción ‘ --help ‘ te dice más; Las opciones ‘ --help=optimizers ‘ y ‘ --help=warnings ‘ le ofrecen un par de cientos de líneas de salida. Las advertencias incluyen:

 -Wunused This switch lacks documentation -Wunused-function Warn when a function is unused -Wunused-label This switch lacks documentation -Wunused-macros Warn about macros defined in the main file that are not used -Wunused-parameter Warn when a function parameter is unused -Wunused-value Warn when an expression value is unused -Wunused-variable Warn when a variable is unused 

Añadido : este es un script llamado glint que utilizo para desinfectar mi código. Es bastante antiguo, por lo que no usa la notación ‘ #!/bin/sh ‘ para la primera línea y dice ‘ $* ‘ en lugar de ‘ "$@" ‘, ambos deben ser fijos, pero ninguno de los dos necesita para ser reparado con urgencia. Tenga en cuenta que aunque GCC 4.x ya no admite la -fwriteable-strings-fwriteable-strings ‘, sigue siendo compatible con la -Wwrite-strings-Wwrite-strings ‘ y eso tiene valor.

Este script demuestra que puede obtener una gran cantidad de kilometraje de las herramientas existentes con solo una pequeña cantidad de trabajo. Puede configurar casi todas las opciones que utiliza, aunque principalmente a través del entorno en lugar de la línea de comandos. Por supuesto, puede agregar opciones de advertencia adicionales a la línea de comando; lo que no puede hacer es eliminar las opciones predeterminadas, excepto a través del entorno. Pero eso esta bien; Son elegidos por defecto por buenas razones. En estos días, probablemente establezca ‘ GLINT_ANSI=-std=c99 ‘ o arregle el script; No lo he estado utilizando mucho últimamente ya que codifico bastante cerca del estándar que impone glint . (Tenga en cuenta que ‘ -o /dev/null ‘ significa que solo puede hacer un archivo a la vez; ¡córtelo para arreglarlo!)

 : "@(#)$Id: glint.sh,v 1.5 2002/08/09 21:40:52 jleffler Exp jleffler $" # # Use GCC as excruciatingly pedantic lint # Not a complete replacement for lint -- it doesn't do inter-file checking. # Now configurable via the environment. # Use GLINT_EXTRA_FLAGS to set extra flags via the environment. # NB: much Solaris code won't work with -undef enabled. : ${GLINT_GCC:='gcc'} : ${GLINT_ANSI='-ansi'} : ${GLINT_FNO_COMMON='-fno-common'} : ${GLINT_FSHORT_ENUMS='-fshort-enums'} : ${GLINT_PEDANTIC='-pedantic'} : ${GLINT_UNDEF='-undef'} : ${GLINT_W='-W'} : ${GLINT_WAGGREGATE_RETURN='-Waggregate-return'} : ${GLINT_WALL='-Wall'} : ${GLINT_WCAST_ALIGN='-Wcast-align'} : ${GLINT_WCAST_QUAL='-Wcast-qual'} : ${GLINT_WCONVERSION='-Wconversion'} : ${GLINT_WMISSING_DECLARATIONS='-Wmissing-declarations'} : ${GLINT_WREDUNDANT_DECLS='-Wredundant-decls'} : ${GLINT_WMISSING_PROTOTYPES='-Wmissing-prototypes'} : ${GLINT_WNESTED_EXTERNS='-Wnested-externs'} : ${GLINT_WPOINTER_ARITH='-Wpointer-arith'} : ${GLINT_WSHADOW='-Wshadow'} : ${GLINT_WSTRICT_PROTOTYPES='-Wstrict-prototypes'} : # ${GLINT_WTRADITIONAL='-Wtraditional'} : ${GLINT_WWRITE_STRINGS='-Wwrite-strings'} exec ${GLINT_GCC} \ ${GLINT_ANSI} \ ${GLINT_FNO_COMMON} \ ${GLINT_FSHORT_ENUMS} \ ${GLINT_PEDANTIC} \ ${GLINT_UNDEF} \ ${GLINT_WAGGREGATE_RETURN} \ ${GLINT_WALL} \ ${GLINT_WCAST_ALIGN} \ ${GLINT_WCAST_QUAL} \ ${GLINT_WCONVERSION} \ ${GLINT_WMISSING_DECLARATIONS} \ ${GLINT_WREDUNDANT_DECLS} \ ${GLINT_WMISSING_PROTOTYPES} \ ${GLINT_WNESTED_EXTERNS} \ ${GLINT_WPOINTER_ARITH} \ ${GLINT_WSHADOW} \ ${GLINT_WSTRICT_PROTOTYPES} \ ${GLINT_WTRADITIONAL} \ ${GLINT_WWRITE_STRINGS} \ ${GLINT_W} \ ${GLINT_EXTRA_FLAGS} \ -o /dev/null -O4 -g -c $* 

Lint es la herramienta clásica para verificar el estilo en los progtwigs en C Hay una encarnación más moderna de ella llamada Splint. Esta entrada de Wikipedia tiene una lista de herramientas de análisis de código estático, algunas gratuitas y otras comerciales.

Aunque estoy seguro de que esta no es una lista completa de herramientas de análisis de código estático , aquí están mis impresiones de algunas diferentes con las que he trabajado en el pasado. (Trabajo principalmente con C.)

  1. Splint : a menudo uso Splint porque está disponible para muchas distribuciones de GNU / Linux. Es relativamente fácil trabajar con él; sin embargo, tiende a ser abrumador cuando se opera en los entornos más estrictos. Además, el uso a veces necesario de las anotaciones puede desordenar y ofuscar código fácilmente legible. En cualquier caso, sugiero usarlo.

  2. Uno : Uno es definitivamente prometedor, pero no es tan riguroso como Splint (por diseño). En cambio, se enfoca en la claridad y utilidad de sus advertencias. Para mí, Uno solo es útil como complemento de Splint (para señalar claramente las advertencias ocultas entre los muchos problemas de Splint comparativamente).

  3. PC-lint : encuentro que PC-lint es difícil de manejar para un progtwig propietario. Una vez lo usé cuando desarrollé para MS-DOS y los nombres crípticos que usa para sus errores lo hicieron muy difícil de usar. Por lo que escucho, hay muchos mejores productos para usar en MS-DOS.

  4. Pscan : ( Hipervínculo muerto) ¡Pscan es excelente para encontrar vulnerabilidades de cadenas de formato! Al igual que con Uno, sugiero usarlo como un suplemento de Splint.

Si no trabaja con C, también puede consultar: Wikipedia: lista de herramientas para el análisis de código estático, herramientas de inspección / revisión, analizadores estáticos de código fuente / binario y analizadores de seguridad de código fuente .

Si ejecuta gcc con -Wall, detectará algunas de las cosas que menciona, como las variables no utilizadas (y quizás las funciones no utilizadas). En términos de optimizaciones, no lo hago, aunque en general el comstackdor es lo suficientemente inteligente como para realizar los tipos de optimizaciones que importan, por lo que no me preocuparía demasiado. Simplemente no uses algoritmos horribles. 😉

La férula ( http://www.splint.org/ ) es bastante excelente; Lo he usado en códigos Megaline para buscar este tipo de cosas,

(Actualizado: todo el mundo quiere ser un director de arte.)

¿Qué le parece usar un generador de perfiles y encontrar qué código se está ejecutando más y enfocarse en esas partes?

Tal vez gprof puede ayudar?

/ Johan

Edición: O como ha hablado de limpieza, invierta mi respuesta anterior y elimine el código que nunca se ejecuta.