Detección de código muerto en un proyecto heredado de C / C++ [cerrado]

Compilar bajo gcc con-Wunreachable-code.

Creo que cuanto más reciente sea la versión, mejores resultados obtendrás, pero puedo estar equivocado en mi impresión de que es algo en lo que han estado trabajando activamente. Tenga en cuenta que esto hace análisis de flujo, pero no creo que le diga acerca de "código" que ya está muerto en el momento en que sale del preprocesador, porque eso nunca es analizado por el compilador. Tampoco detectará, por ejemplo, funciones exportadas que nunca se llaman, o funciones especiales código de manejo de casos que simplemente resulta imposible porque nada llama a la función con ese parámetro, necesita cobertura de código para eso (y ejecutar las pruebas funcionales, no las pruebas unitarias. Las pruebas unitarias se supone que tienen una cobertura de código del 100%, y por lo tanto ejecutan rutas de código que están "muertas" en lo que respecta a la aplicación). Aún así, con estas limitaciones en mente, es una manera fácil de comenzar a encontrar las rutinas más completamente mezcladas en el código basar.

Este aviso de CERT enumera algunas otras herramientas para la detección estática de código muerto

Su enfoque depende de las pruebas de disponibilidad (automatizadas). Si tiene un conjunto de pruebas en el que confía para cubrir una cantidad suficiente de funcionalidad, puede usar un análisis de cobertura, como ya se sugirieron las respuestas anteriores.

Si no tiene tanta suerte, es posible que desee buscar en herramientas de análisis de código fuente como SciTools' Understand that can help you analyse your code using a lot of built in analysis reports. Mi experiencia con esa herramienta data de hace 2 años, así que no puedo darte muchos detalles, pero lo que sí recuerdo es que tenían un soporte impresionante con tiempos de respuesta muy rápidos de correcciones de errores y respuestas a preguntas.

Encontré una página en análisis estático de código fuente que enumera muchas otras herramientas también.

Si eso tampoco te ayuda lo suficiente, y estás específicamente interesado en averiguar el código muerto relacionado con el preprocesador, te recomendaría que publiques más detalles sobre el código. Por ejemplo, si es en su mayoría en relación con varias combinaciones de configuraciones # ifdef, podría escribir scripts para determinar las (combinaciones de) configuraciones y averiguar qué combinaciones nunca se construyen realmente, etc.

G++ 4.01-Wunreachable-code advierte sobre el código que es inalcanzable dentro de una función, pero no advierte sobre las funciones no utilizadas.

int foo() { 
    return 21; // point a
}

int bar() {
  int a = 7;
  return a;
  a += 9;  // point b
  return a;
}

int main(int, char **) {
    return bar();
}

G++ 4.01 emitirá una advertencia sobre el punto b, pero no dirá nada sobre foo() (punto a) a pesar de que es inalcanzable en este archivo. Este comportamiento es correcto aunque decepcionante, porque un compilador no puede saber que la función foo() no es declarada extern en alguna otra unidad de compilación e invocada desde allí; solo un enlazador puede estar seguro.

Solo para código C y suponiendo que el código fuente de todo el proyecto está disponible, inicie un análisis con la herramienta de código abierto Frama-C. Cualquier declaración del programa que se muestra en rojo en la GUI es código muerto.

Si tiene problemas de "código muerto", también puede estar interesado en eliminar "código de repuesto", código que se ejecuta pero no contribuir al resultado final. Esto requiere que usted proporcione una modelización precisa de las funciones de E/S (no te gustaría para eliminar un cálculo que parece ser "de repuesto", pero esto se usa como argumento para printf). Frama-C tiene una opción para señalar código de repuesto.

Tanto Mozilla como Open Office tienen soluciones propias.

Un análisis de código muerto como este requiere un análisis global de todo el proyecto. No puedes obtener esta información analizando unidades de traducción individualmente (bueno, puedes detectar entidades muertas si están completamente dentro de una sola unidad de traducción, pero no creo que eso sea lo que realmente estás buscando).

Hemos utilizado nuestro Kit de herramientas de Reingeniería de Software DMS para implementar exactamente esto para el código Java, analizando todas las unidades de compilación involucradas a la vez, construyendo tablas de símbolos para todo y persiguiendo todas las referencias. Una definición de nivel superior sin referencias y sin pretensión de ser un elemento de API externo está muerta. Esta herramienta también elimina automáticamente el código muerto, y al final puede elegir lo que desea: el informe de entidades muertas, o el código despojado de esas entidades.

DMS también analiza C++ en una variedad de dialectos (EDITAR Feb 2014: incluyendo las versiones MS y GCC de C++14 [EDITAR Nov 2017: ahora C++17]) y construye todo el símbolo necesario tabla. Rastrear las referencias muertas sería sencillo desde ese punto. DMS también podría ser utilizado para despojarlos. Véase http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Bullseye herramienta de cobertura ayudaría. Sin embargo, no es gratis.