Advertencias del compilador

Por lo general, es seguro ignorar algunas advertencias pero si lo hace, con el tiempo se multiplicarán hasta que llegue el día en que haya tantas que no vea la advertencia que realmente importa porque está oculta. en el ruido.

Repare las advertencias de inmediato (lo que puede incluir la desactivación de reglas individuales si cree que nunca es relevante para su contexto).

Mi opinión es que debes ser estricto contigo mismo. El compilador ha sido escrito por expertos totales en el idioma. Si informan que algo es un poco pesado (piense en el olor del código), entonces se debe revisar el código.

Es completamente posible escribir código que se compile sin errores y sin advertencias.

Cuando escribía en C y C ++, habilitaba las configuraciones más estrictas que podía porque quería saber cuándo algo no tenía sentido para el compilador. Cuando terminé de emitir y verificar los valores de retorno, estaría feliz porque el código era tan correcto como podría hacerlo.

Ocasionalmente obtendría un código de otra persona que emitiría advertencias. La verificación de la fuente mostró que estaban ignorando cosas que eran una buena práctica de programación en C, haciendo que su código fuera frágil.

Entonces, creo que hay buenas razones para permitir el rigor y tomarse el tiempo para arreglar las cosas. Hacer lo contrario es descuidado. Si tuviera un compañero de trabajo que desactivara las advertencias, pasaría algún tiempo con ellos Y el gerente explicando por qué eso es realmente malo.

Arreglaría cualquier advertencia. Si los ignora y los deja acumular, es posible que se pierda algo importante.

En general, deberías esforzarte por silenciar el compilador, para que las nuevas advertencias muestren más. Estas advertencias pueden indicar errores sutiles y deben manejarse en consecuencia.

Con respecto a la corrección del código de otras personas, depende en gran medida de la cultura de su lugar de trabajo y del estado actual del código. No puede simplemente modificar el código si activa un ciclo de reevaluación completo, como lo haría para el código al final de la fase de prueba o en producción.

Pregúntale a tu jefe y actúa en consecuencia.

Cada vez que vea una advertencia del compilador, debe detenerse y pensar si realmente es un problema esperar a explotar en la cara en el sitio del cliente, o algo que puede ignorar. Peor aún, las cosas que puede ignorar HOY pueden ser cosas que explotarán en el sitio del cliente en unos pocos años, después de un cambio de código aparentemente no relacionado en algún otro lugar.

Corrige las advertencias. Período. Es eso o documente cada uno de ellos, con tantas páginas de explicación como sean necesarias para demostrar que no es un riesgo, acompañado de una orden de venta firmada por su novia favorita (o alijo de pornografía) si resulta que ERA un riesgo.

Generalmente, quieres que tu compilación esté libre de avisos. Las advertencias están ahí por una razón, y a menudo apuntan a problemas muy reales. Si adquiere el hábito de ignorar las advertencias del compilador, finalmente su compilación tendrá un montón de ellas, y perderá la única advertencia causada por un problema catastrófico que le costará mucho a su compañía. Por otro lado, si su programa normalmente se compila sin advertencias, entonces cada nueva advertencia se notará de inmediato y se podrá resolver rápidamente.

Habiendo dicho eso, a veces los compiladores pueden tener advertencias que tienen poco sentido y que no se pueden corregir fácilmente. Me enfrento a esta situación todos los días en el trabajo con TI CodeComposer, que es un entorno de desarrollo para los DSP de TI. Tengo un código C ++ que compila sin advertencias en Visual Studio, pero que produce advertencias extrañas en CodeComposer, simplemente porque el soporte de TI para C ++ estándar podría ser mejor. Afortunadamente, CodeComposer le permite deshabilitar advertencias específicas individualmente, que es lo que tenemos que hacer cuando no hay forma de corregir el código que produce la advertencia.

En mi caso, las advertencias provienen de la herramienta PyLint y puedo desactivar una advertencia en una línea en particular agregando un texto especial en los comentarios.

En la mayoría de los casos, no hago eso. En la mayoría de los casos, cambio el código para seguir lo que sugiere PyLint porque PyLint generalmente es correcto. Sin embargo, en disgustos constructos que generalmente son una mala idea, pero que tienen sentido en un contexto particular. Por ejemplo, se queja si detecto todas las excepciones posibles. Por lo general, es correcto, sería una mala idea. Sin embargo, en algunos casos quiero capturar todas las excepciones, como enviarme un informe de error con los detalles.

Entonces: en casi todos los casos, deshacerse de los hacks. Cuando el hackeo esté realmente justificado, agregue un comentario que indique que PyLint está de acuerdo.

Las advertencias y los errores son mensajes que el compilador usa para decirle al programador que "algo que escribiste no tuvo sentido". La diferencia entre ellos es que con una advertencia, el compilador está dispuesto a hacer una conjetura sobre el programador. intenciones, mientras que con un error, el compilador ni siquiera puede hacer una conjetura.

Desde un punto de vista sociológico, los programas que tienen muchos mensajes de advertencia son Windows roto .