c++ - compilar - gcc linux
Advertencias del compilador C/C++: ¿borras todo tu código para eliminarlos o dejarlos? (18)
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 los 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?
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.
En mi trabajo, la configuración del compilador para tratar las advertencias como errores está activada. Entonces, no hay advertencias, o no se compilará :)
Estoy de acuerdo en que es mejor eliminar todas las advertencias. Si recibes miles de advertencias, debes priorizar tus soluciones.
Comience configurando su compilador al 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 que alcance el 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 desactiva 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 desactivar 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.
Hay algunos casos en los que dejaré advertencias en código o en las que no es posible limpiarlas (aunque eliminé las que sí puedo). Por ejemplo:
- Si tiene algo en lo que está trabajando y sabe que necesita más trabajo / atención, deje una advertencia para indicar que puede ser apropiado.
- Si está 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 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.
He trabajado con varios 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.
Intento compilar el código con un nivel bastante alto de advertencias y limpiarlas todas, a excepción de 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.
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 está equivocado (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 (cualquier persona que actualice de gcc 3.xa 4.x debería estar familiarizado con eso), así que límpiala ahora.
Algunos compiladores emitirán 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.
Límpielos, incluso si no indican un problema real. De lo contrario, si aparece una advertencia que indica que hay un problema real, no lo verá a través de todo el ruido.
La base de código en 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. Solo podemos compilar en VC ++ 6.
La peor parte es que cuando escribes un código nuevo, es difícil saber si accidentalmente has introducido más advertencias, ya que hay tantas que simplemente las ignoras de todos modos.
El problema con limpiarlos a todos, es que toma tiempo que usted pueda o no tener. Pero sí, en general, debes limpiar todos los que puedas.
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.
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 limpio todo lo que puedo.
No me gustan las 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.
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.
Hay formas de eliminar una advertencia (por ejemplo, #pragma argsused).
Deje que el compilador haga el trabajo.
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 limpia todas sus advertencias, la lista de advertencias seguirá creciendo y los casos reales se perderán en un mar de ruido de advertencia.
Siempre limpie 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).
Una de las características de un programador realmente bueno es que el código incorrecto les da un estómago revuelto.
Me esfuerzo por tener todo mi código no solo limpio, sino también limpio dentro de mi IDE 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.
Yo limpiaría cualquier advertencia. Incluso los que usted sabe que son inofensivos (si tal cosa existe) le darán una mala impresión a cualquiera que compile el código.
Es uno de los signos "huele mal" que buscaría si tuviera que trabajar en el código de otra persona.
Si no se trata de errores reales o posibles problemas futuros, sería una señal de descuido