Pourquoi devriez-vous supprimer les directives using C# inutiles ?

Question

Par exemple, j'ai rarement besoin de :

using System.Text;

mais il est toujours là par défaut. Je suppose que l'application utilisera plus de mémoire si votre code contient des directives using inutiles. Mais y a-t-il autre chose dont je devrais être conscient?

De plus, est-ce que cela fait une différence quelconque si la même directive using est utilisée dans un seul fichier par rapport à la plupart/de tous les fichiers?

---

Remarque: Cette question ne concerne pas le concept non lié appelé une déclaration "using", conçue pour aider à gérer les ressources en veillant à ce que lorsque qu'un objet sort du domaine, sa méthode IDisposable.Dispose soit appelée. Voir Utilisations de "using" en C#.

Answer 1

Il y a quelques raisons pour supprimer les utilisations/espaces de noms inutilisés, en plus de la préférence en matière de codage:

• Supprimer les clauses using inutilisées dans un projet peut accélérer la compilation car le compilateur a moins d'espaces de noms à rechercher pour résoudre les types. (ceci est particulièrement vrai pour C# 3.0 en raison des méthodes d'extension, où le compilateur doit rechercher tous les espaces de noms pour trouver les méthodes d'extension pour d'éventuels meilleurs correspondances, l'inférence de types génériques et les expressions lambda impliquant des types génériques)
• Peut potentiellement aider à éviter les collisions de noms dans les futures constructions lorsque de nouveaux types sont ajoutés aux espaces de noms inutilisés qui ont le même nom que certains types des espaces de noms utilisés.
• Réduira le nombre d'éléments dans la liste de complétion automatique de l'éditeur lors de la saisie de code, ce qui pourrait conduire à une frappe plus rapide (en C# 3.0, cela peut également réduire la liste des méthodes d'extension affichées)

Ce que la suppression des espaces de noms inutilisés ne fait pas:

• Modifier de quelque manière que ce soit la sortie du compilateur.
• Modifier de quelque manière que ce soit l'exécution du programme compilé (chargement plus rapide, ou meilleure performance).

L'assembly résultant est le même avec ou sans les utilisations/espaces de noms inutilisés supprimés.

Answer 2

Cela ne changera rien lorsque votre programme s'exécute. Tout ce qui est nécessaire est chargé à la demande. Donc même si vous avez cette instruction using, à moins que vous n'utilisiez réellement un type dans cet espace de noms / assembly, l'assembly auquel cette instruction using est liée ne sera pas chargé.

Principalement, c'est juste pour nettoyer par préférence personnelle.

Answer 3

La propreté du code est importante.

On commence à avoir le sentiment que le code pourrait ne pas être maintenu et être sur la voie du chantier en friche lorsqu'on voit des using superflus. Fondamentalement, quand je vois des déclarations using inutilisées, un petit drapeau jaune se lève à l'arrière de mon cerveau me disant de "procéder avec prudence". Et lire du code en production ne devrait jamais vous donner ce sentiment.

Alors nettoyez vos using. Ne soyez pas négligent. Inspirez confiance. Rendez votre code joli. Donnez à un autre développeur ce sentiment de bien-être.

Answer 4

Il n'y a pas de construction IL qui correspond à using. Ainsi, les instructions using n'augmentent pas la mémoire de votre application, car aucun code ou donnée n'est généré pour cela.

Using est utilisé au moment de la compilation uniquement dans le but de résoudre les noms de types courts en noms de types complets. Ainsi, le seul effet négatif des using inutiles est de ralentir un peu la compilation et de consommer un peu plus de mémoire pendant la compilation. Je ne m'en inquiéterais pas cependant.

Ainsi, le seul véritable effet négatif d'avoir des instructions using dont vous n'avez pas besoin se situe au niveau de l'intellisense, car la liste des correspondances potentielles pour la complétion pendant la saisie augmente.

Answer 5

Vous pouvez rencontrer des conflits de noms si vous appelez vos classes comme les classes (non utilisées) dans l'espace de noms. Dans le cas de System.Text, vous aurez un problème si vous définissez une classe nommée "Encoder".

Quoi qu'il en soit, il s'agit généralement d'un problème mineur, détecté par le compilateur.