Advertencias del compilador

Muchos compiladores tienen mensajes de advertencia para advertir a los programadores sobre posibles errores de tiempo de ejecución, lógica y rendimiento, la mayoría de las veces, los corrige rápidamente, pero ¿qué pasa con las advertencias no reparables?

¿Cómo se manejan las advertencias no fijables? ¿Vuelve a escribir una parte del código, o lo reescribe de la "manera larga y sin trucos" o deshabilita todas las advertencias? ¿Cuál debería ser la mejor práctica?

¿Qué sucede si está editando el código de otra persona y su código tiene advertencias?

Aquí hay un buen ejemplo: jQuery tiene muchas advertencias de JavaScript cuando se detecta un navegador de clase Mozilla, ¿por qué los desarrolladores de jQ no las arreglan? Si contribuye a jQuery, ¿los va a arreglar?

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 se pierda la única advertencia que realmente importa porque está oculta en el ruido.

Repare las advertencias de inmediato (que pueden incluir la desactivación de reglas individuales si considera 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 raro (piense en el olor del código), entonces el código debe revisarse.

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

Cuando escribía en C y C ++, habilitaba la configuración más estricta 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 lo más correcto posible.

De vez en cuando recibía código de otra persona que arrojaba advertencias. La comprobación de la fuente mostró que ignoraban cosas que eran buenas prácticas de programación en C, haciendo que su código fuera frágil.

Entonces, creo que hay buenas razones para permitir la rigurosidad 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 algo realmente malo.

Arreglaría cualquier advertencia. Si los ignoras y dejas que se acumulen, en realidad podrías perderte algo importante.

En general, debe esforzarse por silenciar el compilador, de modo que las nuevas advertencias muestren más. Estas advertencias pueden indicar errores sutiles y deben manejarse en consecuencia.

Con respecto a la fijación del código de otras personas, depende en gran medida tanto de la cultura de su lugar de trabajo como del estado actual del código. No puede simplemente alterar el código si activa un ciclo completo de reevaluación, como lo haría para el código al final de la fase de prueba o en la 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 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 años, después de un cambio de código aparentemente no relacionado en algún otro lugar.

Arregla las advertencias. Período. Es eso o documenta cada uno de ellos, con tantas páginas de explicación como sea necesario para demostrar que no es un riesgo, acompañado de una orden de venta firmada con tu novia favorita (o escondite porno) si resulta que ERA un riesgo.

En general, desea que su compilación esté libre de advertencias. Las advertencias están ahí por una razón, y a menudo apuntan a problemas muy reales. Si tiene el hábito de ignorar las advertencias del compilador, eventualmente su compilación tendrá un montón de ellas, y perderá la única advertencia causada por un problema catastrófico que le costará caro a su compañía. Por otro lado, si su programa normalmente se compila sin advertencias, entonces cada nueva advertencia se nota de inmediato y se puede abordar rápidamente.

Dicho esto, a veces los compiladores pueden tener advertencias que tienen poco sentido y que no pueden repararse 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 TI DSP. Tengo un código C ++ que se compila sin advertencias en Visual Studio, pero que genera 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 arreglar 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 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 suele ser correcto. Sin embargo, en los disgustos, construcciones que generalmente son una mala idea, pero que tienen sentido en un contexto particular. Por ejemplo, se queja si atrapo todas las excepciones posibles. Por lo general, es correcto, sería una mala idea. Sin embargo, en algunos casos quiero detectar todas las excepciones, como enviarme un informe de error con los detalles.

Entonces: en casi todos los casos, deshazte de los hacks. Cuando el truco esté realmente justificado, agregue un comentario diciéndole a PyLint que está bien.

Algunos de los beneficios de la rigurosidad no se establecieron claramente en las otras respuestas:

1. Cuando se han solucionado todas las advertencias fácilmente reparables, es más probable que aparezcan las advertencias significativas / relevantes restantes.
2. Si las advertencias relevantes se encuentran y se abordan a tiempo (antes del lanzamiento), se pueden evitar errores, lo que lleva a una mejor satisfacción del usuario final
3. Resolver la advertencia generalmente conduce a un código más fácil de mantener (por ejemplo, eliminando condiciones que siempre son verdaderas)
4. Cuando la cantidad de advertencias está más cerca de 0, es fácil acordar la Política de Advertencias Cero en el equipo, que es muy fácil de automatizar en el sistema CI.
5. Al resolver las advertencias del compilador, se profundiza la comprensión del código del programa, lo que puede conducir a información útil sobre la implementación (por ejemplo, descubrir otros errores u obtener ideas sobre cómo desarrollar aún más el código)
6. La compilación se acelera, la productividad diaria aumenta: IDE / compilador tiene menos problemas para administrar e informar, por lo que la compilación es más rápida (esto solo es relevante en el contexto de miles de advertencias).

Existen diferencias específicas de idioma en ciertos tipos de advertencias. Creo que es importante pensar y debatir sobre el tema y luego desactivar algunas advertencias individuales si se sienten totalmente inútiles para que se pueda lograr la rigurosidad. Esto se ha logrado en varios equipos en mi carrera. Más sobre mis experiencias sobre el tema.

Las advertencias y los errores son mensajes que el compilador usa para decirle al programador "algo que usted escribió no tenía sentido". La diferencia entre ellos es que con una advertencia, el compilador está dispuesto a adivinar las intenciones del programador, mientras que con un error, el compilador ni siquiera puede adivinar.

Los errores del compilador se resolverán (no voy a decir que se corrigieron ), pero con demasiada frecuencia, los programadores (incluso los experimentados) ignorarán las advertencias. El problema de ignorar las advertencias es que a veces el compilador adivina mal y si tiene más de 1000 mensajes de advertencia, es fácil pasar por alto un mensaje de advertencia que indica que el compilador está adivinando mal.

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