Discussion :

[saraInfoSab]

Bonjour,
J'utilise checkstyle et il me soulève plusieurs warnings pour déclarer qu'une méthode doit être finale, je me retrouve avec des milliers d'erreur.
Je me demande si c'est intéressant d'activer checkstyle si on oublie de mettre final aux méthodes qu'on ne redéfinit pas, et quelles sont les points positifs et négatifs à déclarer une méthode ou un attribut finale(coté performances par exemple).
Merci.

[deathness]

Pour la performance je te suggère cette lecture:
http://www.javaperformancetuning.com/tips/final.shtml

Sinon la principale utilité est pour la relecture du code : on indique clairement que tel attribut ou paramètre de méthode ne va pas changer. C'est particulièrement intéressant pour les objets en paramètre de méthode, que ce soit pour indiquer cela, ou alors autre utilité pour forcer l'implémentation à ne pas modifier le paramètre.

Pour les méthodes, cela sert à interdire les redéfinitions.

[tchize_]

A mon avis t'as configuré ton checkstyle pour être très très spépieux

Personellement, je n'ai jamais définis de paramètre finaux. Pour les champs, ça dépend de l'usage. Coté performances, je n'ai jamais rémarqué de différence. Pour ce qui est des méthodes, c'est en théorie plus performant de mettre final, mais en pratique c'est surtout très génant. Ce n'est pas parceque, aujourd'hui, tu ne surcharge pas cette méthode que demain tu n'en aura pas besoin.

[JoeChip]

Ce n'est pas parceque, aujourd'hui, tu ne surcharge pas cette méthode que demain tu n'en aura pas besoin.

Oui, donc en fait tu met "final" pour que le compilo te sorte une erreur quand tu la surcharge. Pas mal de ces trucs de style sont là pour ça, pour que le compilo balance un faux positif plutot que de prendre le risque d'avoir une run-time, ou qu'un (autre ?) stagiaire change un truc, plus tard.

Du coup beaucoup rigidifient tout, un peu comme pour les GUI, où certains ont tendance à y aller en coordonnées absolues, histoire de tout contrôler.

En pratique, tu configures CheckStyle pour qu'il ne beepe pas toutes les cinq minutes, autrement dit, pour qu'il te signale ce qui risque d'être une erreur parce que tu ne fais pas comme tu trouvais normal de faire quand tu as configuré CheckStyle, je ne sais pas si je me fais bien comprendre.

C'est comme les erreurs dans Eclipse : tu peux décider qu'un truc est un fatal, un warning ou un ignore selon ta manière de faire.

[deathness]

En pratique, tu configures CheckStyle pour qu'il ne beepe pas toutes les cinq minutes, autrement dit, pour qu'il te signale ce qui risque d'être une erreur parce que tu ne fais pas comme tu trouvais normal de faire quand tu as configuré CheckStyle, je ne sais pas si je me fais bien comprendre.

A la deuxième relecture si

C'est clair que c'est pas pour les perfs qu'il faut le mettre. Mais je trouve que pour la compréhension lors d'une relecture/maintenance de code ça a une réelle utilité.
De même pour le codeur lorsqu'il veut vraiment signaler qu'un objet ne doit pas être modifié!