Veo que tienes las típicas respuestas cliched aquí. “¡Cada advertencia puede ser un error, así que corrígelos todos!”, Y “la mayoría de las advertencias NO son errores, ¡por lo que es más riesgo corregirlos!”
Excelente. Un montón de personas que han bebido el koolaid estándar de un lado, o tienen una respuesta emocional de una manera u otra y usan el koolaid estándar de ese lado para defenderlo. Supongo que la mayoría de las otras respuestas provienen de ese lugar, porque, ya saben, así es como se obtienen respuestas superficiales que se han repetido mil veces sin participar realmente en una discusión profunda y significativa de las realidades.
Así que vamos a tener una discusión profunda y significativa de las realidades.
Una advertencia no es exactamente una función de “advertencia sobre posibles errores”. Es el compilador (un intérprete de idiomas) que le dice que ha abusado del idioma de alguna manera. Como un francés que le dice a un americano que trató de hablar francés “Tu francés es terrible. Pero me las arreglé para conseguir lo que dices de todos modos “. El compilador le advierte que puede ser mal entendido, porque no se explicó claramente. Para continuar con la analogía con un chico francés, también puede decirte que una palabra que usaste está desactualizada y que algunos podrían no entenderla, y también puede que te diga que lo que estás pidiendo está mal visto (pero no es ilegal).
Para que quede claro: un compilador no puede advertirle que ha realizado una conversión incorrecta de millas a kilómetros, porque no entiende esos conceptos y no sabe qué son ni por qué lo haría. Un compilador puede advertirle si ha convertido un número a un tipo menos preciso, sin indicar específicamente que desea hacerlo. Eso podría ser un error. Tal vez intentaste truncar ese valor y simplemente olvidaste declararlo explícitamente. Tal vez no quiso truncar ese valor, pero los parámetros operativos son tales que nunca se encuentra el truncamiento. Tal vez no quiso truncar ese valor y los resultados son catastróficos e inmediatamente se evidencia que cometió un error. O tal vez sus pruebas de unidad (usted … tiene pruebas de unidad, ¿verdad? Llegaré a eso) no verificaron los valores lo suficientemente altos, y el truncamiento de valores no se ve hasta algún caso del mundo real donde el valor es más alto que el de cualquiera. Pensado para probar.
Tal vez ese valor fue el valor de empuje del cohete y el valor redondeado acaba de enviar a algunos astronautas a lanzarse hacia el sol. En este caso, tiene un error y la solución típica para la advertencia: “agregar un modelo” reparará la advertencia pero no solucionará el error.
O tal vez ese valor nunca exceda de 255, pero lo lee de una biblioteca que mete todo en enteros de 64 bits, y ahora necesita realizar un cálculo con ese valor contra otros enteros de 16 bits y almacenar el resultado en un campo de 16 bits. . Una vez más, la estrategia estándar de “agregar un reparto” solucionará la advertencia, pero para empezar, nunca hubo ningún error.
Tal vez el compilador le advierte que está comparando un int firmado con un int sin firmar, y lo arregla con un lanzamiento a int sin firmar. Ups. Si la firma firmada fue negativa, su comparación ahora tendrá falsos positivos y falsos negativos. Al corregir la advertencia, causaste un error que no estaba allí antes.
Hecho : la gran mayoría de las advertencias no son errores, y nunca causarán errores.
Hecho: Un pequeño porcentaje de advertencias son errores
Hecho: Un porcentaje muy pequeño de advertencias es catastrófico . Al igual que en, son un error en el que las personas podrían morir, las empresas o las economías podrían colapsar, las personas podrían perder sus empleos (incluido usted).
Hecho: Un pequeño porcentaje de advertencias no son errores, pero intentar solucionarlo es un riesgo de que pueda causar errores.
Ahora es la parte en la que voy a refutar a las personas que dicen que no deben limpiar las advertencias debido al riesgo del último caso. ¿Recuerdas antes cuando pregunté por pruebas de unidad? ¿Esas personas que están preocupadas por causar un error que no estaba allí antes? Es una buena posibilidad que no tengan ninguna prueba de unidad. Porque si tienen buenas pruebas de unidad, las pruebas detectarán su error, ya que no fue un caso no anticipado sino un caso de trabajo conocido que tuvo una buena prueba de unidad, ¿verdad? ¿¡¿¡¿CORRECTO?!?!?
Ahora voy a refutar el argumento de que no vale la pena el esfuerzo porque hay muchas advertencias y casi ninguna tiene errores (también conocido como costo / beneficio).
En dos ocasiones me han dado la propiedad de grandes bases de código existentes que estaban llenas de advertencias. En la primera ocasión, al principio no hice nada y viví con ello durante un año y medio. Entonces tuvimos un error bastante desastroso. Una vez que localicé el error, encontré que el culpable era un trazo de línea, con una advertencia sobre un tipo de problema de seguridad. Esa advertencia, en esa línea de código, habría sido completamente evidente que era una bomba de tiempo. Entonces, ¿por qué no se ha arreglado ya? Porque ese producto tenía más de 10.000 advertencias. Se perdió entre todos los sin sentido. Para ponerlo en términos de procesamiento de señales, la advertencia es una señal de emergencia, y todas las demás advertencias no importantes son ruido. Y al igual que con cualquier otra señal … demasiado ruido y no puede recibir el mensaje.
En ese momento hice de la limpieza de las advertencias una prioridad. Y establecí que era una regla de equipo que una vez que un módulo estaba libre de advertencias, las advertencias como errores se activaban para ese módulo y no se volvían a apagar. Tomó bastante tiempo, pero eventualmente ese código estuvo libre de avisos. En el proceso de limpieza, causamos 10 errores nuevos que fueron detectados rápidamente por nuestras pruebas de rutina y reparados. Encontramos 3 errores menores que nunca se habían reportado, pero que probablemente habían causado un comportamiento extraño en la producción, y 4 errores que también estaban marcando bombas de tiempo de proporciones catastróficas. Esas 4 bombas de tiempo se difundieron antes de explotar, y le ahorré a mi equipo 4 grandes dolores de cabeza.
Te diré algo más que aprendimos. Todas esas advertencias son de salida de cadena desde el compilador. ¡Eso es un montón de datos! Una vez que esas salidas de cadena desaparecieron, nuestro código se compiló más rápido y utilizó menos recursos del sistema durante la compilación. Si ese argumento no te entiende, ¡no sé qué haré!
Así que limpia las advertencias. Porque son peligrosos. Pero hazlo con cuidado. Inspecciona cada caso. Tome su tiempo. Tenga en cuenta las advertencias que tienen más probabilidades de ser errores y las advertencias que probablemente causen errores cuando intente solucionarlos. Y adopte el hábito de no dejar las advertencias en primer lugar con su propio código.