Are Suppress Warning Annotations Bad?

Since version 5 of the Java programming language, it is possible to add meta-information in Java programs by means of annotations. In particular some annotations can be used to customise the behaviour of the compiler. For instance the @SuppressWarnings annotation has the purpose of instructing the compiler to suppress a specific warning in the annotated element (and in all program elements contained in the annotated element).

I posit that a free use of @SuppressWarnings by programmers is not a good practice.

In some cases such annotations allow the programmer to omit some (supposedly) useless parts of a class, e.g. when an application specific exception class that will never be serialised is declared. The the programmer might want to suppress the warning about the need to define a serial version UID:

@SuppressWarnings("serial")
public class MySpecialException extends Exception {
}

In some other cases it can be used to silence the compiler on some pieces of outdated (and possibly deprecated code), e.g.

 for (@SuppressWarnings("rawtypes")  
             Iterator i= legacy.iterator(); i.hasNext();){
 System.out.println(i.next());
 }

I must point out that the same exact result (i.e. silencing the compiler) can be achieved using the following (more compact and generics-compliant) code:

 for (Iterator<?> i = legacy.iterator(); i.hasNext(); ) {
 System.out.println(i.next());
 }

Both examples are, in my view, bad practices since the individual programmer perspective (even if not malicious) may be too narrow w.r.t. the project-level perspective in terms of which warnings can be safely ignored.

I emphasise that this is not just an academic note, I found a few instances of the second pattern – which I consider event worse than the first – in some industrial code.

What do you think?

Annunci

3 thoughts on “Are Suppress Warning Annotations Bad?

  1. I’m for an hard-core old-school approach: warnings *are* errors. Just one kind of errors that don’t block compilation.
    A warning always uncovers some design error, some suboptimal usage of the language, some misunderstanding of library classes, some technical debt, or some plain old laziness or ignorance.
    Always learn from your warnings: they are the voice of the language developers whispering to you. They may be annoying, but always worth.

  2. I am not sure, sometimes either you silence a warning or you have to go through some refactoring operation that could be costly and end up with an over-designed solution, which in my opinion is bad because it leads to code that is more difficult to understand.

    For sure some of these warnings can be dealt with using some automated refactoring utility but sometimes it is not possible and, if the developer knows what is doing, it seems a decent compromise to shut down a specific warning. However I agree that the developer could not have the global vision of the project (and all possible usages of the product) to take this decision.

    I suppose the second kind of annotations (on a local variable declaration) was introduced only in Java 1.7 (but I am not sure about this).

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...