¿Cómo puedo saber qué partes del código nunca se usan?

Tengo un código C ++ heredado del que se supone que debo eliminar el código no utilizado. El problema es que la base del código es grande.

¿Cómo puedo saber qué código nunca se llama / nunca se usa?

Hay dos variedades de código no utilizado:

• el local, es decir, en algunas funciones algunas rutas o variables no se usan (o se usan pero no de manera significativa, como escrito pero nunca leído)
• el global: funciones que nunca se llaman, objetos globales a los que nunca se accede

Para el primer tipo, un buen compilador puede ayudar:

• -Wunused(GCC, Clang ) debe advertir sobre variables no utilizadas, incluso el analizador de Clang no utilizado se ha incrementado para advertir sobre variables que nunca se leen (aunque se usen).
• -Wunreachable-code(GCC anterior, eliminado en 2010 ) debería advertir sobre los bloques locales a los que nunca se accede (sucede con retornos tempranos o condiciones que siempre se evalúan como verdaderas)
• No conozco ninguna opción para advertir sobre catchbloques no utilizados , porque el compilador generalmente no puede probar que no se lanzará ninguna excepción.

Para el segundo tipo, es mucho más difícil. Estáticamente requiere un análisis completo del programa, y ​​aunque la optimización del tiempo de enlace puede eliminar el código muerto, en la práctica el programa se ha transformado tanto en el momento en que se realiza que es casi imposible transmitir información significativa al usuario.

Por lo tanto, hay dos enfoques:

• El teórico es usar un analizador estático. Un software que examinará todo el código de una vez con gran detalle y encontrará todas las rutas de flujo. En la práctica, no sé nada que funcione aquí.
• El pragmático es usar una heurística: use una herramienta de cobertura de código (en la cadena GNU es gcov. Tenga en cuenta que se deben pasar banderas específicas durante la compilación para que funcione correctamente). Ejecuta la herramienta de cobertura de código con un buen conjunto de entradas variadas (sus pruebas unitarias o pruebas de no regresión), el código muerto está necesariamente dentro del código no alcanzado ... y puede comenzar desde aquí.

Si está extremadamente interesado en el tema y tiene el tiempo y la inclinación para desarrollar una herramienta por su cuenta, le sugiero que use las bibliotecas de Clang para crear dicha herramienta.

1. Use la biblioteca de Clang para obtener un AST (árbol de sintaxis abstracta)
2. Realice un análisis de marca y barrido desde los puntos de entrada en adelante

Debido a que Clang analizará el código por usted y realizará una resolución de sobrecarga, no tendrá que lidiar con las reglas de los lenguajes de C ++, y podrá concentrarse en el problema en cuestión.

Sin embargo, este tipo de técnica no puede identificar las anulaciones virtuales que no se utilizan, ya que podrían ser llamadas por código de terceros sobre el que no puede razonar.

Para el caso de funciones completas no utilizadas (y variables globales no utilizadas), GCC puede hacer la mayor parte del trabajo por usted siempre que esté utilizando GCC y GNU ld.

Al compilar la fuente, use -ffunction-sectionsy -fdata-sections, luego, al vincular el uso -Wl,--gc-sections,--print-gc-sections. El enlazador ahora enumerará todas las funciones que podrían eliminarse porque nunca fueron llamadas y todas las globales que nunca fueron referenciadas.

(Por supuesto, también puede omitir la --print-gc-sectionsparte y dejar que el enlazador elimine las funciones en silencio, pero las mantenga en la fuente).

Nota: esto solo encontrará funciones completas no utilizadas, no hará nada sobre el código muerto dentro de las funciones. Las funciones llamadas desde el código muerto en las funciones en vivo también se mantendrán.

Algunas características específicas de C ++ también causarán problemas, en particular:

• Funciones virtuales Sin saber qué subclases existen y cuáles se instancian realmente en tiempo de ejecución, no puede saber qué funciones virtuales necesita para existir en el programa final. El enlazador no tiene suficiente información sobre eso, por lo que tendrá que mantenerlos a todos.
• Globales con constructores, y sus constructores. En general, el vinculador no puede saber que el constructor de un global no tiene efectos secundarios, por lo que debe ejecutarlo. Obviamente, esto significa que lo global también debe mantenerse.

En ambos casos, cualquier cosa utilizada por una función virtual o un constructor de variable global también debe mantenerse.

Una advertencia adicional es que si está creando una biblioteca compartida, la configuración predeterminada en GCC exportará todas las funciones de la biblioteca compartida, haciendo que se "use" en lo que respecta al vinculador. Para solucionarlo, debe establecer el valor predeterminado para ocultar símbolos en lugar de exportar (usando, por ejemplo -fvisibility=hidden), y luego seleccionar explícitamente las funciones exportadas que necesita exportar.

Bueno, si usas g ++ puedes usar esta bandera -Wunused

De acuerdo con la documentación:

Avise siempre que una variable no se use aparte de su declaración, cada vez que una función se declare estática pero nunca se defina, cada vez que se declare una etiqueta pero no se use, y cada vez que una instrucción calcule un resultado que explícitamente no se usa.

http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

Editar : Aquí hay otra bandera útil -Wunreachable-code Según la documentación:

Esta opción tiene como objetivo advertir cuando el compilador detecta que al menos una línea completa de código fuente nunca se ejecutará, porque alguna condición nunca se cumple o porque es después de un procedimiento que nunca regresa.

Actualización : Encontré un tema similar Detección de código muerto en proyecto C / C ++ heredado

Creo que estás buscando una herramienta de cobertura de código . Una herramienta de cobertura de código analizará su código mientras se está ejecutando, y le informará qué líneas de código se ejecutaron y cuántas veces, así como cuáles no.

Puede intentar darle una oportunidad a esta herramienta de cobertura de código fuente abierto: TestCocoon : herramienta de cobertura de código para C / C ++ y C #.

La verdadera respuesta aquí es: nunca se puede saber con certeza.

Al menos, para casos no triviales, no puede estar seguro de haberlo recibido todo. Considere lo siguiente del artículo de Wikipedia sobre código inalcanzable :

double x = sqrt(2);
if (x > 5)
{
  doStuff();
}

Como Wikipedia señala correctamente, un compilador inteligente puede detectar algo como esto. Pero considere una modificación:

int y;
cin >> y;
double x = sqrt((double)y);

if (x != 0 && x < 1)
{
  doStuff();
}

¿El compilador captará esto? Tal vez. Pero para hacer eso, tendrá que hacer más que correr sqrtcontra un valor escalar constante. Tendrá que descubrir que (double)ysiempre será un número entero (fácil), y luego comprender el rango matemático de sqrtpara el conjunto de enteros (difícil). Un compilador muy sofisticado podría hacer esto para la sqrtfunción, o para cada función en math.h , o para cualquier función de entrada fija cuyo dominio pueda resolver. Esto se vuelve muy, muy complejo, y la complejidad es básicamente ilimitada. Puede seguir agregando capas de sofisticación a su compilador, pero siempre habrá una forma de introducir un código que será inalcanzable para cualquier conjunto de entradas.

Y luego están los conjuntos de entrada que simplemente nunca se ingresan. Entrada que no tendría sentido en la vida real, o quedaría bloqueada por la lógica de validación en otro lugar. No hay forma de que el compilador sepa sobre eso.

El resultado final de esto es que, si bien las herramientas de software que otros han mencionado son extremadamente útiles, nunca sabrás con certeza que capturaste todo a menos que revises el código manualmente después. Incluso entonces, nunca estarás seguro de que no te perdiste nada.

La única solución real, en mi humilde opinión, es estar lo más alerta posible, usar la automatización a su disposición, refactorizar donde pueda y buscar constantemente formas de mejorar su código. Por supuesto, es una buena idea hacer eso de todos modos.

No lo he usado yo mismo, pero cppcheck , afirma encontrar funciones no utilizadas. Probablemente no resolverá el problema completo, pero podría ser un comienzo.

Puede intentar usar PC-lint / FlexeLint del software Gimple . Reclama

encuentre macros no utilizados, typedef's, clases, miembros, declaraciones, etc. en todo el proyecto

Lo he usado para análisis estático y lo encontré muy bueno, pero tengo que admitir que no lo he usado para encontrar específicamente un código muerto.

Mi enfoque normal para encontrar cosas no utilizadas es

1. asegúrese de que el sistema de compilación maneja el seguimiento de dependencias correctamente
2. configure un segundo monitor, con una ventana de terminal de pantalla completa, ejecute compilaciones repetidas y muestre la primera pantalla llena de resultados. watch "make 2>&1"tiende a hacer el truco en Unix.
3. ejecutar una operación de buscar y reemplazar en todo el árbol de origen, agregando "//?" al comienzo de cada línea
4. corrige el primer error marcado por el compilador, quitando el "//?" en las líneas correspondientes.
5. Repita hasta que no queden errores.

Este es un proceso algo largo, pero da buenos resultados.

Marque tantas funciones y variables públicas como privadas o protegidas sin causar un error de compilación, mientras hace esto, intente también refactorizar el código. Al hacer que las funciones sean privadas y hasta cierto punto protegidas, redujo su área de búsqueda, ya que las funciones privadas solo se pueden invocar desde la misma clase (a menos que haya estúpidos macro u otros trucos para evitar la restricción de acceso, y si ese es el caso, le recomendaría encontrar un nuevo trabajo). Es mucho más fácil determinar que no necesita una función privada ya que solo la clase en la que está trabajando actualmente puede llamar a esta función. Este método es más fácil si su base de código tiene clases pequeñas y está débilmente acoplada. Si su código base no tiene clases pequeñas o tiene un acoplamiento muy apretado, sugiero limpiarlas primero.

Lo siguiente será marcar todas las funciones públicas restantes y hacer un gráfico de llamadas para descubrir la relación entre las clases. Desde este árbol, intente averiguar qué parte de la rama parece recortada.

La ventaja de este método es que puede hacerlo por módulo, por lo que es fácil seguir pasando la prueba de la unidad sin tener un largo período de tiempo cuando tiene una base de código dañada.

Si está en Linux, es posible que desee buscar callgrinduna herramienta de análisis de programas C / C ++ que forme parte de la valgrindsuite, que también contiene herramientas que comprueban las pérdidas de memoria y otros errores de memoria (que también debería usar). Analiza una instancia en ejecución de su programa y produce datos sobre su gráfico de llamadas y sobre los costos de rendimiento de los nodos en el gráfico de llamadas. Por lo general, se usa para el análisis de rendimiento, pero también produce un gráfico de llamadas para sus aplicaciones, para que pueda ver qué funciones se llaman, así como sus llamadores.

Obviamente, esto es complementario a los métodos estáticos mencionados en otra parte de la página, y solo será útil para eliminar clases, métodos y funciones completamente no utilizados; no ayuda a encontrar código muerto dentro de los métodos que realmente se llaman.

Realmente no he usado ninguna herramienta que haga tal cosa ... Pero, por lo que he visto en todas las respuestas, nadie ha dicho que este problema sea indiscutible.

¿Qué quiero decir con esto? Que este problema no puede ser resuelto por ningún algoritmo en una computadora. Este teorema (que dicho algoritmo no existe) es un corolario del problema de detención de Turing.

Todas las herramientas que usará no son algoritmos sino heurísticas (es decir, no algoritmos exactos). No le darán exactamente todo el código que no se usa.

Una forma es usar un depurador y la función de compilación para eliminar el código de máquina no utilizado durante la compilación.

Una vez que se elimina algún código de máquina, el depurador no le permitirá poner un breakpojnt en la línea correspondiente del código fuente. Por lo tanto, coloca puntos de interrupción en todas partes e inicia el programa e inspecciona los puntos de interrupción, aquellos que están en el estado "sin código cargado para esta fuente" corresponden al código eliminado, o ese código nunca se llama o se ha insertado y debe realizar un mínimo análisis para encontrar cuál de esos dos sucedió.

Al menos así es como funciona en Visual Studio y supongo que otros conjuntos de herramientas también pueden hacerlo.

Eso es mucho trabajo, pero supongo que es más rápido que analizar manualmente todo el código.

CppDepend es una herramienta comercial que puede detectar tipos, métodos y campos no utilizados, y hacer mucho más. Está disponible para Windows y Linux (pero actualmente no tiene soporte de 64 bits), y viene con una prueba de 2 semanas.

Descargo de responsabilidad: no trabajo allí, pero tengo una licencia para esta herramienta (así como NDepend , que es una alternativa más poderosa para el código .NET).

Para aquellos que tienen curiosidad, aquí hay un ejemplo de regla incorporada (personalizable) para detectar métodos muertos, escrita en CQLinq :

// <Name>Potentially dead Methods</Name>
warnif count > 0
// Filter procedure for methods that should'nt be considered as dead
let canMethodBeConsideredAsDeadProc = new Func<IMethod, bool>(
    m => !m.IsPublic &&       // Public methods might be used by client applications of your Projects.
         !m.IsEntryPoint &&            // Main() method is not used by-design.
         !m.IsClassConstructor &&      
         !m.IsVirtual &&               // Only check for non virtual method that are not seen as used in IL.
         !(m.IsConstructor &&          // Don't take account of protected ctor that might be call by a derived ctors.
           m.IsProtected) &&
         !m.IsGeneratedByCompiler
)

// Get methods unused
let methodsUnused = 
   from m in JustMyCode.Methods where 
   m.NbMethodsCallingMe == 0 && 
   canMethodBeConsideredAsDeadProc(m)
   select m

// Dead methods = methods used only by unused methods (recursive)
let deadMethodsMetric = methodsUnused.FillIterative(
   methods => // Unique loop, just to let a chance to build the hashset.
              from o in new[] { new object() }
              // Use a hashet to make Intersect calls much faster!
              let hashset = methods.ToHashSet()
              from m in codeBase.Application.Methods.UsedByAny(methods).Except(methods)
              where canMethodBeConsideredAsDeadProc(m) &&
                    // Select methods called only by methods already considered as dead
                    hashset.Intersect(m.MethodsCallingMe).Count() == m.NbMethodsCallingMe
              select m)

from m in JustMyCode.Methods.Intersect(deadMethodsMetric.DefinitionDomain)
select new { m, m.MethodsCallingMe, depth = deadMethodsMetric[m] }

Depende de la plataforma que use para crear su aplicación.

Por ejemplo, si usa Visual Studio, podría usar una herramienta como .NET ANTS Profiler que puede analizar y perfilar su código. De esta manera, debe saber rápidamente qué parte de su código se usa realmente. Eclipse también tiene complementos equivalentes.

De lo contrario, si necesita saber qué función de su aplicación utiliza realmente su usuario final, y si puede liberar su aplicación fácilmente, puede usar un archivo de registro para una auditoría.

Para cada función principal, puede rastrear su uso y, después de unos días / semana, simplemente obtener ese archivo de registro y echarle un vistazo.

No creo que se pueda hacer automáticamente.

Incluso con las herramientas de cobertura de código, debe proporcionar suficientes datos de entrada para ejecutar.

Puede ser una herramienta de análisis estático muy compleja y de alto precio, como el compilador de Coverity o LLVM, podría ser de ayuda.

Pero no estoy seguro y preferiría la revisión manual del código.

ACTUALIZADO

Bueno ... solo eliminando variables no utilizadas, las funciones no utilizadas no son difíciles.

ACTUALIZADO

Después de leer otras respuestas y comentarios, estoy más convencido de que no se puede hacer.

Debe conocer el código para tener una medida de cobertura de código significativa, y si sabe que mucha edición manual será más rápida que preparar / ejecutar / revisar los resultados de cobertura.

Un amigo me hizo esta misma pregunta hoy, y miré a mi alrededor algunos desarrollos prometedores de Clang, por ejemplo, ASTMatcher s y el Analizador estático que podrían tener suficiente visibilidad en el proceso durante la compilación para determinar las secciones de código muerto, pero luego encontró esto:

https://blog.flameeyes.eu/2008/01/today-how-to-identify-unused-exported-functions-and-variables

Es casi una descripción completa de cómo usar algunos indicadores de GCC que aparentemente están diseñados con el propósito de identificar símbolos sin referencia.

El problema general de si se llamará a alguna función es NP-Complete. No puede saber de antemano de manera general si se llamará a alguna función, ya que no sabrá si una máquina Turing alguna vez se detendrá. Puede obtener si hay alguna ruta (estáticamente) que va desde main () a la función que ha escrito, pero eso no garantiza que alguna vez se llamará.

Bueno, si usas g ++ puedes usar esta bandera -Wunused

De acuerdo con la documentación:

Warn whenever a variable is unused aside from its declaration, whenever a function is declared static but never defined, whenever a label is declared but not used, and whenever a statement computes a result that is explicitly not used.

http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

Editar: Aquí hay otro indicador útil: Código inalcanzable Según la documentación:

This option is intended to warn when the compiler detects that at least a whole line of source code will never be executed, because some condition is never satisfied or because it is after a procedure that never returns.