Cómo lidiar con las advertencias en un proyecto heredado

Trabajo en un proyecto C ++ que genera miles de millones de advertencias. La mayoría de las advertencias aparecieron después de escribir el código:

• Inicialmente, el proyecto usó Visual C ++ 8, luego cambió a 9, pero hay poca diferencia en las advertencias generadas. Las advertencias fueron fijadas o silenciadas, por lo que no hubo advertencias entonces.
• Luego se agregó un objetivo de 64 bits. Generó una gran cantidad de advertencias, principalmente debido al uso descuidado de los tipos (por ejemplo, unsignedvs. size_t). Nadie se molestó, o tuvo tiempo, para arreglarlos una vez que el código funcionó para ese propósito.
• Luego se agregó soporte para otras plataformas que usan GCC (4.5 y 4.6, algunas 4.4 inicialmente). GCC es mucho más exigente, por lo que generó muchas más advertencias. De nuevo, nadie se molestó ni tuvo tiempo para arreglarlos. Esto se complicó por el hecho de que GCC no tenía un pragma para silenciar una advertencia en un bit de código particular hasta 4.5, y de acuerdo con la documentación todavía no es lo que uno necesitaría.
• Mientras tanto, aparecieron algunas advertencias obsoletas.

Así que ahora tenemos un proyecto que genera miles de advertencias. Y ni siquiera puedo decir desde cuántos lugares, ya que incluso los .cpparchivos son compilados varias veces por diferentes compiladores y las advertencias en los encabezados se imprimen una y otra vez.

¿Existe alguna práctica recomendada para limpiar algo así? ¿O al menos alguna experiencia positiva al tratarlo?

No toques ninguno de los códigos heredados. Encuentre una manera de suprimir las advertencias por ahora. Hacer cambios aparentemente inocuos en el código puede introducir errores en el código que, supongo, ya ha sido probado y está relativamente libre de errores.

Al suprimir todas las advertencias que están actualmente en la base de código, puede pretender tener una pizarra limpia. Deben eliminarse todas las advertencias nuevas introducidas en el código, y cuando se reescribe el código antiguo, la nueva implementación no debe suprimir las advertencias.

Sus objetivos aquí deberían ser:

1. Reduzca la relación señal / ruido. Si los desarrolladores ven miles de avisos cuando compilan, no notarán que la rama maestra tiene avisos de 2004 y su rama tiene 2006.

2. No introduzca más errores. Al realizar los cambios inocuos mencionados anteriormente, podría estar introduciendo errores imprevistos. Esto es especialmente pertinente cuando tienes miles de advertencias. Incluso si su tasa de error es increíblemente baja, aún tiene miles de posibilidades de equivocarse.

3. No permita que el código heredado baje sus estándares para el nuevo código. El hecho de que se suprimieron las advertencias para una clase no significa que la nueva clase pueda hacer lo mismo. Finalmente, con diligencia, el código heredado se eliminará de la base de código y se reemplazará con un código más nuevo y sin advertencia.

Creo que las advertencias, que no se tratan como errores, son inútiles. Obtienes toneladas de ellos, por lo tanto, nadie se molesta en mirarlos y pierden su propósito.

Mi sugerencia es solucionarlos todos y comenzar a tratarlos como errores.
Arreglarlos parece aterrador, pero creo que se puede hacer. Un buen programador que se encargaría de este trabajo pronto descubrirá la manera de lidiar con cada advertencia y lo manejará de manera muy mecánica y rápida.

Hicimos un proyecto similar en mi empresa, y funcionó: ahora no tenemos advertencias en la parte del código donde es importante para nosotros, y estoy hablando de muchos miles de archivos (no sé cuántas advertencias) .

Esto debe seguirse inmediatamente tratando las advertencias como errores. Una vez que una parte de su código esté libre de advertencias, cambie los indicadores de compilación para esta parte y no permita que entren nuevas advertencias. Si no lo hace, encontrará nuevas advertencias emergentes como hongos, y su trabajo se desperdiciará.

Una preocupación que puede tener es la introducción de errores como resultado de la reparación de las advertencias. Esto es especialmente probable porque el programador que repara las advertencias probablemente no conoce la mayor parte del código que está cambiando. Sin embargo, la mayoría de los cambios serían muy seguros, por ejemplo, agregar un prototipo de función o un elenco.

Estaba leyendo Estándares de codificación C ++: 101 reglas, pautas y mejores prácticas y la segunda de las pautas sugiere "Compilar la limpieza a niveles de advertencia altos". Esboza una serie de razones por las cuales no querría tantas advertencias en un programa y las principales entre ellas son

1. Hay un problema potencial en su código.
2. Debe tener compilaciones silenciosas y exitosas y, de lo contrario, es posible que le falten problemas reales.
3. Las advertencias benignas ignoradas podrían oscurecer las advertencias que apuntan a peligros reales

Los programas que se compilan con advertencias pueden parecer correctos, pero es posible que haya problemas reales con el código que pueden surgir en algún momento. Sugeriría categorizar las advertencias, darles un nivel de priorización y, cuando tenga tiempo, corregirlas.

Deje de lado un ciclo / sprint para realizar un mantenimiento preventivo en el sistema, eliminar el código muerto, eliminar advertencias, eliminar comentarios negativos, cosas por el estilo, O instituir una política para eliminar las advertencias ya que las fuentes se tocan de todas formas para otra cosa.
Yo no haría lo primero solo para deshacerme de las advertencias, pero si se planificara ese ciclo, eso sería parte de la carga de trabajo. La razón de esto es que tocar un archivo para cualquier cosa introduce riesgo de errores y, por lo tanto, arriesga la estabilidad de su producto.

Siento tu dolor porque estoy en una situación similar. La forma en que abordé el problema es: elimine las advertencias de un módulo / subproyecto en ese momento y configure el indicador del compilador "tratar advertencias como error" (Werr) para el módulo después de que se haya limpiado. Además, decidí centrarme solo en una plataforma, aunque construimos sobre varios sistemas operativos con diferentes compiladores. Finalmente, para las bibliotecas de terceros que compilamos, solo apago las advertencias.

Eso sí, deshacerse de algunas de estas advertencias es mucho más fácil decirlo que hacerlo. Por ejemplo, los problemas de size_t vs unsigned que mencionas pueden causar desbordamientos de enteros si solo silencias las advertencias con conversiones, por lo que en algunos casos reemplazas unsigned con size_t, en otros casos necesitas detectar un desbordamiento en tiempo de ejecución. Todo es caso por caso, muy tedioso y difícil.