Pourquoi devriez-vous supprimer les directives C # inutiles à l'aide de directives?


216

Par exemple, j'ai rarement besoin:

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 d'utilisation inutiles . Mais y a-t-il autre chose dont je devrais être conscient?

En outre, cela fait-il une différence si la même directive using est utilisée dans un seul fichier par rapport à la plupart / tous les fichiers?


Edit: Notez que cette question ne concerne pas le concept sans rapport appelé instruction using , conçu pour aider à gérer les ressources en s'assurant que lorsqu'un objet sort du domaine, sa méthode IDisposable.Dispose est appelée. Voir Utilisations de «l'utilisation» en C # .

Réponses:


181

Cela ne changera rien lors de l'exécution de votre programme. 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 l'instruction using est corrélée ne sera pas chargé.

Principalement, c'est juste pour nettoyer selon vos préférences personnelles.


@francip - c'est ce que je dis. l'utilisation n'affecte pas le chargement de l'assembly, un assembly n'est pas chargé jusqu'à ce qu'un type contenu dans l'assembly soit référencé.
Darren Kopp, le

69
mais cela peut affecter le temps de compilation et la réactivité d'Intellisense / IDE.
Marchy


475

Il y a peu de raisons de supprimer les espaces / noms non utilisés, en plus de la préférence de codage:

  • la suppression des clauses using inutilisées dans un projet peut accélérer la compilation car le compilateur a moins d'espaces de noms pour rechercher les types à résoudre. (Cela est particulièrement vrai pour C # 3.0 en raison des méthodes d'extension, où le compilateur doit rechercher dans toutes les espaces de noms des méthodes d'extension pour de meilleures correspondances possibles, une inférence de type générique et des expressions lambda impliquant des types génériques)
  • peut potentiellement aider à éviter la collision de noms dans les générations futures lorsque de nouveaux types sont ajoutés aux espaces de noms inutilisés qui portent le même nom que certains types dans les espaces de noms utilisés.
  • réduira le nombre d'éléments dans la liste de saisie semi-automatique de l'éditeur lors du codage, conduisant éventuellement à une saisie 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 fera pas :

  • modifier en aucune façon la sortie du compilateur.
  • modifier en aucune façon l'exécution du programme compilé (chargement plus rapide, ou meilleures performances).

L'assemblage résultant est le même avec ou sans utilisation de (s) utilisation (s) retirée (s).


3
Et lorsque vous modifiez des fichiers, vous finirez par ajouter de plus en plus d'espaces de noms au début des fichiers. Donc, si vous ne supprimez pas les espaces de noms inutilisés, lorsque vous ouvrez le fichier, tout ce que vous voyez est une liste géante d'espaces de noms au lieu d'une implémentation réelle.
Mert Akcakaya

5
Concernant la compilation plus rapide: les usingdirectives inutilisées dans les .csfichiers peuvent vous empêcher de supprimer certaines références d'assemblage (autrement inutilisées) de votre .csprojprojet. Si vous avez une "solution" de nombreux projets, des références inutiles entre les projets forceront les projets à être compilés dans un ordre spécifique alors qu'en fait ils sont indépendants et peuvent être compilés en parallèle. Supprimez donc les usingdirectives inutilisées avant de vérifier les références de projet inutilisées dans une solution à plusieurs projets.
Jeppe Stig Nielsen du

1
C'est une excellente explication - au final, cela n'a pas grand-chose à voir avec les performances mais plutôt avec les meilleures pratiques. Merci d'avoir expliqué!
GSaunders

39

La propreté du code est importante.

On commence à avoir le sentiment que le code peut être non maintenu et sur le chemin du front quand on voit des utilisations superflues. Essentiellement, quand je vois des déclarations d'utilisation inutilisées, un petit drapeau jaune monte à l'arrière de mon cerveau me disant de "procéder avec prudence". Et la lecture du code de production ne devrait jamais vous donner ce sentiment.

Alors nettoyez vos utilisations. Ne soyez pas bâclé. Inspirer la confiance. Rendez votre code joli. Donnez à un autre développeur ce sentiment chaud et flou.


Voilà ce que je voulais entendre :-) Je suis habitué à faire de Organize Usings -> Remove and Sorttemps en temps. BTW, pour moi, les deux options supérieures Organize Usingssont sans signification. Je parle de VS2013 btw.
Sнаđошƒаӽ

30

Il n'y a pas de construction IL correspondant using. Ainsi, les usinginstructions n'augmentent pas la mémoire de votre application, car aucun code ou donnée n'est généré pour elle.

Usingest utilisé au moment de la compilation uniquement dans le but de résoudre des noms de type courts en noms de type pleinement qualifiés. Ainsi, le seul effet négatif inutile usingpeut avoir est de ralentir un peu le temps de compilation et de prendre un peu plus de mémoire pendant la compilation. Je ne serais cependant pas inquiet à ce sujet.

Ainsi, le seul véritable effet négatif d'avoir des usinginstructions dont vous n'avez pas besoin est sur intellisense, car la liste des correspondances potentielles à compléter pendant que vous tapez augmente.


4

Vous pouvez rencontrer des conflits de noms si vous appelez vos classes comme les classes (inutilisé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, c'est généralement un problème mineur, et détecté par le compilateur.


2

Votre application n'utilisera pas plus de mémoire. C'est pour que le compilateur trouve les classes que vous utilisez dans les fichiers de code. Cela ne fait vraiment pas de mal au-delà de ne pas être propre.


2

C'est une préférence personnelle principalement. Je les nettoie moi-même (Resharper fait un bon travail de me dire quand il n'y a pas besoin d'utiliser des déclarations).

On pourrait dire que cela pourrait réduire le temps de compilation, mais avec les vitesses de l'ordinateur et du compilateur de nos jours, cela n'aurait tout simplement aucun impact perceptible.


2

Laisser des usingdirectives supplémentaires est très bien. Il y a un peu de valeur à les supprimer, mais pas beaucoup. Par exemple, cela rend mes listes d'achèvement IntelliSense plus courtes et donc plus faciles à parcourir.

Les assemblys compilés ne sont pas affectés par des usingdirectives étrangères .

Parfois, je les mets à l'intérieur d'un #regionet le laisse s'effondrer; cela rend la visualisation du fichier un peu plus propre. OMI, c'est l'une des rares bonnes utilisations de #region.


1
Ils peuvent s'effondrer sans région
abatishchev

1
@abatishchev: Oui, c'est vrai dans VS2010.
Jay Bazuzi

"L'une des rares bonnes utilisations de #region", alors vous voulez dire que l'utilisation #regionest mauvaise à bien des égards?
Steven

Oui, #regionc'est une odeur de code. Cela dit qu'il se passe trop de choses dans votre classe.
Jay Bazuzi

2

si vous souhaitez conserver votre code propre, les usinginstructions non utilisées doivent être supprimées du fichier. les avantages apparaissent très clairement lorsque vous travaillez dans une équipe collaborative qui a besoin de comprendre votre code, pensez que tout votre code doit être maintenu, moins de code = moins de travail, les avantages sont à long terme.


1

Ils sont juste utilisés comme raccourci. Par exemple, vous devez écrire: System.Int32 à chaque fois si vous ne disposez pas d'un système utilisant; en haut.

La suppression de ceux inutilisés rend simplement votre code plus propre.


1

L'instruction using vous empêche simplement de qualifier les types que vous utilisez. J'aime personnellement les nettoyer. Cela dépend vraiment de la façon dont une métrique loc est utilisée


1

Le fait de ne disposer que des espaces de noms que vous utilisez réellement vous permet de conserver votre code documenté.

Vous pouvez facilement trouver les parties de votre code qui s'appellent par n'importe quel outil de recherche.

Si vous avez des espaces de noms inutilisés, cela ne signifie rien lors de l'exécution d'une recherche.

Je travaille sur le nettoyage des espaces de noms maintenant, car on me demande constamment quelles parties de l'application accèdent aux mêmes données d'une manière ou d'une autre.

Je sais quelles parties accèdent aux données dans chaque sens en raison de l'accès aux données séparé par des espaces de noms, par exemple directement via une base de données et en direct via un service Web.

Je ne peux pas penser à un moyen plus simple de faire tout cela à la fois.

Si vous voulez juste que votre code soit une boîte noire (pour les développeurs), alors oui, cela n'a pas d'importance. Mais si vous devez le maintenir au fil du temps, c'est une documentation précieuse comme tout autre code.


0

L'instruction `` using '' n'affecte pas les performances car elle n'est qu'une aide pour qualifier les noms de vos identifiants. Ainsi, au lieu d'avoir à taper System.IO.Path.Combine (...) , vous pouvez simplement taper Path.Combine (...) si vous utilisez System.IO .


0

N'oubliez pas que le compilateur fait beaucoup de travail pour tout optimiser lors de la construction de votre projet. Utiliser cela est utilisé à beaucoup d'endroits ou 1 ne devrait pas faire différent une fois compilé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.