Y a-t-il une raison de nettoyer les importations inutilisées en Java, si ce n'est pour réduire l'encombrement ?

Question

Y a-t-il une bonne raison d'éviter les déclarations d'importation inutilisées en Java ? D'après ce que je comprends, elles sont là pour le compilateur, donc beaucoup d'importations inutilisées n'auront pas d'impact sur le code compilé. S'agit-il simplement de réduire l'encombrement et d'éviter les conflits de noms à l'avenir ?

(Je pose la question parce qu'Eclipse donne un avertissement sur les importations inutilisées, ce qui est assez ennuyeux lorsque je développe du code parce que je ne veux pas supprimer les importations avant d'être pratiquement sûr d'avoir fini de concevoir la classe).

Answer 1

Je ne pense pas que des problèmes de performance ou quelque chose de ce genre soient probables si vous ne retirez pas les importations.

Mais il pourrait y avoir des conflits de noms, dans de rares cas comme l'importation de l'interface de la liste.

Dans Eclipse, vous pouvez toujours utiliser un raccourci (qui dépend du système d'exploitation - Win : Ctrl + SHIFT + O et Mac : COMMAND + SHIFT + O ) pour organiser les importations. Eclipse nettoie ensuite la section d'importation en supprimant toutes les importations périmées, etc. Si vous avez à nouveau besoin d'un élément importé, Eclipse l'ajoutera automatiquement pendant que vous compléterez la déclaration avec la commande Ctrl + SPACE . Il n'est donc pas nécessaire de conserver du code inutilisé dans votre classe.

Comme toujours, le code inutilisé vous distraira, vous et d'autres personnes, pendant la lecture du code. Laisser quelque chose dans votre code actif parce que j'en aurai peut-être besoin plus tard est généralement considéré comme une mauvaise pratique.

Answer 2

L'une d'elles est que si vous supprimez la classe référencée par l'importation du classpath, vous n'obtiendrez pas une erreur de compilation stupide qui n'a servi à rien. Et vous n'obtiendrez pas de faux positifs lorsque vous effectuerez une recherche "where used".

Une autre possibilité (mais elle serait de nature très spécifique) serait que l'importation inutilisée ait des conflits de noms avec une autre importation, ce qui vous obligerait à utiliser inutilement des noms entièrement qualifiés.

Addendum : Aujourd'hui, le serveur de compilation a commencé à échouer la compilation (même pas le test d'exécution) avec une erreur de mémoire insuffisante. Il a toujours fonctionné sans problème et les vérifications n'ont révélé aucun changement dans le processus de compilation ou d'ajouts importants qui pourraient expliquer cela. Après avoir essayé d'augmenter les paramètres de mémoire (il s'agit d'une JVM 64 bits sur un CentOS 64 bits !) à quelque chose de bien au-delà de ce que les clients peuvent compiler, j'ai examiné les check-ins un par un.

Il y avait une importation incorrecte qu'un développeur avait utilisée et abandonnée (il avait utilisé la classe, l'avait importée automatiquement, puis s'était rendu compte que c'était une erreur). Cette importation inutilisée a entraîné un niveau séparé de l'application qui, bien que l'IDE ne soit pas configuré pour les séparer, le processus de construction l'est. Cette importation unique a entraîné tant de classes que le compilateur a tenté de compiler sans avoir les bibliothèques dépendantes pertinentes dans le classpath, ce qui a causé tant de problèmes qu'il a provoqué l'erreur "out of memory". Il a fallu une heure pour résoudre ce problème causé par une importation inutilisée.

Answer 3

D'un point de vue puriste, toute dépendance constitue une "contrainte" sur le produit et peut donc causer des problèmes de maintenance ultérieurement.

Par exemple, supposons que votre programme utilise la classe com.X.Y.Z.ObjectPool, et que plus tard vous décidez de ne plus l'utiliser mais ne supprimez jamais l'importation. Si quelqu'un d'autre veut maintenant instancier org.W.V.Y.ObjectPool et simplement faire référence à ObjectPool, il ne sera pas averti jusqu'à ce qu'il y ait un problème de casting ou d'invocation.

Ce n'est d'ailleurs pas un scénario irréaliste. Chaque fois qu'Eclipse vous a demandé quelle version spécifique de X vous vouliez importer, et que vous en avez choisi une parmi de nombreux paquets, c'est un scénario où, si vous aviez fait l'importation à cet endroit, vous auriez pu obtenir le mauvais choix sans le savoir.

Dans tous les cas, vous pouvez demander à Eclipse de les nettoyer pour vous.

Answer 4

Avertissement ? Demandez à Eclipse de les nettoyer automatiquement pour vous. C'est ce que fait IntelliJ. S'il est assez intelligent pour vous avertir, il devrait être assez intelligent pour les nettoyer. Je vous recommande de chercher un paramètre d'Eclipse pour lui dire d'arrêter d'être un tel casse-pieds et de faire quelque chose.

Answer 5

Cela a trait à la clarté du programme utile pour la maintenance.

Si vous deviez maintenir un programme, vous verriez combien il est utile d'avoir une seule importation de classe par ligne.

Réfléchissez au scénario suivant :

import company.billing.*;
import company.humanrerources.*;

// other imports 

class SomeClass {
      // hundreds or thousands of lines here... 
    public void veryImportantMethod() {
      Customer customer;
      Employee comployee;
      Department dept. 
      // do something with them
     }
 }

Lorsque vous corrigez des bogues ou maintenez un morceau de code (ou que vous le lisez simplement), il est très utile pour le lecteur de savoir à quel paquetage appartiennent les classes utilisées. L'utilisation de l'import joker comme indiqué ci-dessus n'est pas utile à cette fin.

Même avec un IDE, vous ne voulez pas survoler ou sauter à la déclaration et au retour, c'est plus facile si vous comprenez en termes de fonctionnalité de quels autres paquets et classes le code actuel dépend.

Si c'est pour un projet personnel ou quelque chose de petit, cela n'a pas vraiment d'importance, mais pour quelque chose de plus grand qui doit être utilisé par d'autres développeurs (et maintenu au fil des ans), c'est un MUST HAVE.

Il n'y a absolument aucune différence de performance avec aucun d'entre eux.