¿Es una buena práctica utilizar advertencias de supresión en su código?

Utilizo @SuppressWarnings("unchecked")y @SuppressWarnings("null")sobre todo los métodos anteriores para permitir que el código se compile sin advertencias, pero tengo mis dudas. Encontré esta pregunta de Stackoverflow . Jon Skeet escribió una respuesta que encuentro intrigante.

De acuerdo con él,

A veces, los genéricos de Java simplemente no te permiten hacer lo que quieres y debes decirle al compilador de manera efectiva que lo que estás haciendo realmente será legal en el momento de la ejecución.

Pero, ¿qué pasa si existe la posibilidad de que se produzca una excepción? ¿No es una mala idea suprimir las advertencias? ¿No debería estar al tanto de los lugares donde podrían surgir problemas?

Además, ¿qué pasa si alguien más modifica mi código más tarde y agrega alguna funcionalidad cuestionable sin eliminar SuppressWarnings? ¿Cómo se puede evitar eso y / o hay alguna otra alternativa a esto?

¿Debo estar usando @SuppressWarnings("unchecked")y @SuppressWarnings("null")?

Actualización n. ° 1

En cuanto a los tipos de conversión no verificados, según esta respuesta (señalada por @gnat en los comentarios a continuación), es necesario suprimir estas advertencias.

Muchas bibliotecas Java indispensables nunca se han actualizado para eliminar la necesidad de tipos de letra inseguros. Es necesario suprimir esas advertencias para que otras advertencias más importantes se noten y corrijan.

En caso de suprimir otras advertencias, todavía en un área gris.

Actualización n. ° 2

Según Oracle Docs (también mencionado por algunas respuestas a continuación):

Como cuestión de estilo, los programadores siempre deben usar esta anotación en el elemento más anidado donde sea efectivo. Si desea suprimir una advertencia en un método en particular, debe anotar ese método en lugar de su clase.

Para mí, el objetivo de suprimir las advertencias es mantener una "declaración de salud limpia" para su proyecto. Si sabe que toda su base de código se compila limpiamente, es inmediatamente obvio cuando alguien hace algo mal que hace que la primera advertencia aparezca en la lista de problemas. Luego puede corregir el error o suprimirlo si puede probar que es falso.

Pero si tiene 21 advertencias para comenzar, es mucho más probable que pase por alto la 22 cuando alguien la causa, y no verifica que sea inofensiva. Eso significa que los problemas pueden colarse en su base de código y nunca lo notará.

Las advertencias son elementos útiles de información. Asegúrate de prestar atención a los que dicen la verdad y filtra los que no. No permita que las personas mezclen los dos tipos para que pierda su sistema de alerta temprana.

Editar

Probablemente debería aclarar que suprimir una advertencia que tiene mérito es algo tonto. Una declaración de salud limpia que obtuviste haciendo trampa obviamente no vale nada. Dada la opción, siempre debe solucionar el problema que el compilador notó en lugar de simplemente cerrar los ojos. Sin embargo, hay áreas en las que el compilador no puede estar seguro de si algo será un problema o no (los genéricos de Java son una de esas áreas), y la mejor opción es revisar cada una de esas instancias y luego suprimir la advertencia en este lugar específico. que apagar esta clase de advertencia por completo y potencialmente perder una genuina.

La supresión de advertencias es algo que debe hacerse con extremo cuidado.

Una advertencia significa: el compilador encontró algo que parece dudoso. No significa que sea dudoso, solo lo parece para el compilador. A veces tienes un código que está perfectamente bien y da una advertencia. A veces lo arreglas modificando ligeramente tu código. Algunas veces el compilador tiene alguna característica específicamente para ese propósito. Por ejemplo donde

if (x = someFunction ()) { ... }

da una advertencia pero

if ((x = someFunction ())) { ... }

no lo hace En el primer caso, una advertencia asumiendo que posiblemente quisiste decir == y no =. En el segundo caso no hay advertencia porque los paréntesis adicionales le dicen al compilador "Sé lo que estoy haciendo". Mejor, por supuesto, sería

if ((x = someFunction ()) != 0) { ... }

o usando dos líneas.

Y a veces, muy raramente, hay casos en que su código está bien, pero no puede escribirlo de una manera que sea aceptada sin previo aviso. En ese caso muy, muy raro, deshabilita una advertencia para esa declaración y la activa inmediatamente después. Ese es un último recurso. Y solo deshabilita esa advertencia específica, no otras.

Sin embargo, algunas personas simplemente deshabilitan las advertencias para deshacerse de las advertencias, porque son demasiado flojas para descubrir y solucionar primero el motivo de una advertencia legítima. O ni siquiera intentan escribir código libre de advertencias. Eso es algo muy poco saludable que hacer.

Suprimir la advertencia de un método completo es sospechoso. Es mejor suprimir las advertencias para la línea específica, con un comentario . p.ej

@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast