Bonjour,

Cela fais un moment que j'utilise Java (pour un usage surtout personnel), et je me pose de plus en plus régulièrement des questions concernant la propreté de mon code ainsi que son optimisation; chose que je faisais beaucoup moins au début où je souhaitai uniquement que mon code fonctionne. Autant certaines questions ont des réponses tout bêtes ou très simple à trouver sur internet autant celle-ci, je la trouve un peu plus complexe. Je viens donc demander votre aide pour m'éclairer d'une manière plus efficace que sur les topic en anglais que j'ai pu trouver (je me débrouille mais ne suis pas un expert en anglais).

Je développe en ce moment une librairie pour m'éviter d'avoir à recommencer mon code à chaque mini-projet ou à le copier coller, j'ai donc une bonne partie de mes fonctions qui sont considéré comme inutilisés, ce qui m’emmena à me poser la question suivante: @SuppressWarnings("unused") qu'apporte donc se bout de code à part m'éviter les warnings de mon IDE (IntelliJ), car je ne pense pas qu'il servent juste à cela; ça doit bien avoir une autre utilité et j'aurais aimé savoir laquelle. Ainsi que dans quel cas est-il réellement utilisé ?

Merci d'avoir pris le temps de vous intéressé à ma question.

-
Edité par ThéoBoutron 26 mai 2016 à 3:30:09

Salut,

L'annotation suppressWarnings est uniquement utilisée pour donner des informations complémentaires au compilateur et ainsi éviter de signaler au développeur des choses dont il connaît les risques.

Bonjour.

Les warnings sont là parce qu'il y a quelque qui ne va pas, même si non-bloquant.
Personnellement je suis contre les @SuppressWarnings : il faut corriger le problème à la source.

Il arrive toutefois (1% des cas) que l'on ne puisse pas faire autrement.
Je préfère laisser visible le warning pour pouvoir le traiter plus tard. 

Il arrive toutefois (1% des cas) que l'on ne puisse pas faire autrement.

Comme pour les classes génériques qui font râler le compilo.

D'accord et bien merci à vous

Si tu as trouvé une réponse à ta question, merci de passer ton sujet en résolu !

Songbird239 a écrit:

Il arrive toutefois (1% des cas) que l'on ne puisse pas faire autrement.

Comme pour les classes génériques qui font râler le compilo.

Pas si c'est bien respecté.

Pour un cast depuis un fichier yml par exemple, le compilateur est incapable de savoir ce qu'il va se passer (ni le dev d'ailleurs), à ce moment-là il n'y a pas vraiment d'alternatives.