Advertencias del compilador C/C++: ¿limpia todo su código para eliminarlas o dejarlas?

Question

He trabajado en muchos proyectos en los que otros me han proporcionado código para actualizar. La mayoría de las veces lo compilo y obtengo más de 1,000 advertencias de compilador. Cuando veo las advertencias del compilador me hacen sentir sucio, así que mi primera tarea es limpiar el código y eliminarlos todos. Normalmente encuentro alrededor de una docena de problemas, como variables no inicializadas.

No entiendo por qué las personas las dejan y no tienen compilaciones perfectamente limpias sin advertencias. ¿Me estoy perdiendo de algo? ¿Hay alguna razón válida para dejarlos? ¿Alguna historia de terror para compartir?

Answer 1

Limpiaré cualquier advertencia. Incluso los que usted sabe que son inofensivos (si tal cosa existe) le darán una mala impresión de quién compilará el código.

Es uno de los signos "mal olor", buscaría si tuviera que trabajar en otra cosa código.

Si no errores reales o potenciales problemas futuros, sería un signo de dejadez

Answer 2

me gusta advertencias. Los elimino tanto como sea posible.
A veces, cuando estoy bajo presión para terminar el trabajo, les dejo algunos. Aunque rara vez los dejo. Me siento como tú, sucio si queda algo.

Answer 3

En mi trabajo, la configuración del compilador para tratar las advertencias como errores está activada. Por lo tanto, no hay advertencias, o no compilará :)

Answer 4

Siempre limpie sus advertencias. Si tiene un caso específico en el que sabe que la advertencia es correcta, suprímalo solo para esa instancia.

Si bien algunas advertencias pueden ser benignas, la mayoría significa un problema real con el código.

Si no limpiar todas sus advertencias a continuación, la lista de alerta continuará creciendo y los casos reales de problemas se pierde en un mar de advertencia ruido.

Answer 5

La base de código con la que trabajo tiene más de 4000 advertencias. Algunos de ellos son problemas legítimos. Nunca tenemos tiempo para entrar y arreglarlos, ni refactorizar otras cosas rotas ... En parte, esto se debe a que el código es tan antiguo que es anterior a C++ estandarizado. Sólo se puede compilar en VC++ 6.

Answer 6

Una de las características de un programador muy bueno es que el código mal les da el estómago revuelto.

Me esfuerzo para que todos los de mi código no sólo compilador limpia, sino también estar limpio dentro de mi IDE establece en un nivel bastante exigente. A veces necesito suprimir una instancia de advertencia si sé mejor que la herramienta, pero al menos eso también sirve como documentación.

Answer 7

Lo peor es que cuando se escribe código nuevo, es difícil saber si se ha introducido accidentalmente más advertencias, ya que hay muchos que simplemente ignorarlos todos modos.

El problema con limpiarlos a todos, es que lleva tiempo que usted pueda o no tener. Pero sí, en general, debes limpiar todos los que puedas.

Answer 8

Límpielos, incluso si no indican un problema real. De lo contrario, si aparece una advertencia de que indica que aparece un problema real, no lo verá a través de todo el ruido.

Answer 9

Las advertencias son y deben ser tratadas como errores.Si no puede codificar lo suficiente como para deshacerse de sus advertencias, entonces probablemente no debería codificar. En mi grupo tomamos la decisión de forzar todas las advertencias a errores. Termina esta discusión por completo y realmente, en mi humilde opinión, mejora la calidad del código.

Answer 10

Limpie siempre todas las advertencias o suprímalas explícitamente si es necesario. La configuración predeterminada para las advertencias debe ser lo más alta posible al compilar (nivel 4 en VS, por ejemplo).

Answer 11

Acepto que es mejor eliminar todas las advertencias. Si recibes miles de advertencias, debes priorizar tus soluciones.

Comience configurando el compilador en el nivel de advertencia más bajo. Estas advertencias deberían ser las más importantes. Cuando estos sean fijos, incremente su nivel de advertencia y repita hasta llegar al nivel de advertencia más alto. Luego configure sus opciones de compilación para que las advertencias sean tratadas como errores.

Si encuentra una advertencia que sospecha que es seguro ignorar, investigue un poco para verificar su teoría. Solo entonces deshabilítelo y solo de la manera más mínima posible. La mayoría de los compiladores tienen directivas #pragma que pueden deshabilitar/habilitar advertencias solo para una parte de un archivo. Aquí hay un ejemplo de Visual C++:

typedef struct _X * X; // from external header, not 64-bit portable 

#pragma warning(push) 
#pragma warning(disable: 4312) // 64-bit portability warning 
X x = reinterpret_cast<X>(0xDDDDDDDD); // we know X not 64-bit portable 
#pragma warning(pop) 

Tenga en cuenta que esto solo deshabilita la advertencia de una sola línea de código. El uso de este método también le permite hacer búsquedas simples de texto de su código en el futuro para realizar cambios.

Alternativamente, generalmente puede deshabilitar una advertencia particular para un solo archivo o para todos los archivos. En mi humilde opinión esto es peligroso y solo debería ser un último recurso.

Answer 12

Límpielos si es posible. En una base de código multiplataforma/multi-compilador (he trabajado en una compilación en 7 sistemas operativos diferentes con 6 compiladores diferentes), eso no siempre es posible. He visto casos en los que el compilador es incorrecto (HP-UX aCC en Itanium, te estoy mirando), pero eso es ciertamente raro. Como otros señalan, puede desactivar la advertencia en tal situación.

Muchas veces, lo que es una advertencia en esta versión del compilador puede convertirse en un error en la próxima versión (cualquiera que actualice desde gcc 3.xa 4.x debería estar familiarizado con eso), así que límpiala ahora.

Algunos compiladores emiten advertencias realmente útiles que se convertirán en problemas en determinadas circunstancias: Visual C++ 2005 y 2008 pueden advertirle acerca de los problemas de 64 bits, que es un gran beneficio en la actualidad. Si tiene planes de migrar a 64 bits, simplemente limpiar ese tipo de advertencias reducirá drásticamente el tiempo de su puerto.

Answer 13

En algunos casos dejaré advertencias en el código, o cuando no sea posible limpiarlas (aunque eliminé las que sí puedo). Por ejemplo:

• Si usted tiene algo que está trabajando, y usted sabe que necesita más trabajo/atención, dejando una advertencia en su lugar para indicar que esto puede ser apropiado
• Si estás compilando C++ con/clr, hay varias advertencias sobre cosas que hacen que se genere código nativo; puede ser engorroso suprimir todas estas advertencias cuando la base de código no se puede cambiar funcionalmente
• Limpiar las advertencias cuando no entiende lo que hace la corrección. He hecho esto un par de veces con una advertencia de PC-Lint, y terminé introduciendo errores. Si no sabe cuál es el efecto exacto del cambio (por ejemplo: moldes de estilo C para eliminar advertencias), NO lo haga. Averiguar la advertencia, o dejar el código solo es mi consejo.

De todos modos, esas son las instancias fuera de mi cabeza donde dejar advertencias podría ser apropiado.

Answer 14

He trabajado con una serie de sistemas integrados en los que las advertencias darán lugar a inestabilidad, bloqueos o daños en la memoria. A menos que sepa que la advertencia es inocua, debería tratarse.

Answer 15

Dejar advertencias en su código porque no tiene tiempo para arreglarlas es como no cepillarse los dientes porque no tiene suficiente tiempo por la mañana. Es una cuestión básica de higiene del código.

Answer 16

Siempre habilito todas las advertencias, y luego configuro mi proyecto para detener la construcción si hay advertencias.

Si hay advertencias, debe verificar cada una de ellas para asegurarse de que no haya ningún problema. Hacer esto una y otra vez es una pérdida de tiempo. No hacer esto implica dará lugar a errores que se arrastran en su código.

Existen varias formas de eliminar una advertencia (por ejemplo, #pragma argsused).

Deje que el compilador haga el trabajo.

Answer 17

Mi jefe que creó un código que ahora mantengo. Utiliza banderas de compilación para ocultar sus advertencias de privación.

Cuando tengo tiempo, reviso y borro todo lo que puedo.

Answer 18

Intento compilar el código con un nivel bastante alto de advertencias y limpiarlas todas, excepto las advertencias "de comparación firmada/sin firmar", que estoy seguro de que debería corregir, pero nunca me molestarán.

Versión corta: en g ++ utilizo "-Wextra -Wno-sign-compare" y me deshago de todos los mensajes.