Pourquoi devriez-vous supprimer les directives d’utilisation inutiles de C #?
Par exemple, j'ai rarement besoin de:
using System.Text;
mais c'est toujours là par défaut. Je suppose que l'application utilisera plus de mémoire si votre code contient des éléments inutiles en utilisant des directives . Mais y a-t-il autre chose que je devrais être au courant?
De plus, 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 non lié appelé un sing statement , conçu pour aider l’utilisateur à gérer les ressources en veillant à ce que, lorsqu'un objet sort de la portée, Sa méthode IDisposable.Dispose est appelée. Voir tilisations de "using" en C # .
Cela ne changera rien lorsque votre programme sera exécuté. Tout ce dont vous avez besoin est chargé à la demande. Ainsi, 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 avec lequel utiliser est corrélé ne sera pas chargé.
Principalement, il s'agit simplement de nettoyer par préférence personnelle.
Il y a sont quelques raisons de supprimer les utilisations/espaces de noms inutilisés, en plus des préférences 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 à rechercher pour 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 les espaces de noms des méthodes d'extension pour de meilleures correspondances possibles, l'inférence de type générique et les 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 nom inutilisés et portent le même nom que certains types des espaces de nom utilisés.
- réduira le nombre d'éléments de la liste de saisie semi-automatique de l'éditeur lors du codage, ce qui entraînera éventuellement une saisie plus rapide (en C # 3.0, cela peut également réduire la liste des méthodes d'extension affichées)
Qu'est-ce que la suppression des espaces de noms inutilisés ne sera pas faire:
- 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 meilleures performances).
L'assemblage obtenu est identique, avec ou sans utilisation non utilisée (s) supprimée (s).
Code de propreté est important.
On commence à avoir l’impression que le code peut ne pas être maintenu et sur le chemin de Browfield quand on voit des utilisations superflues. En substance, lorsque je vois des instructions d’utilisation inutilisées, un petit drapeau jaune se lève à l’arrière de mon cerveau me disant de "procéder avec prudence". Et lire le code de production ne devrait jamais vous donner ce sentiment.
Alors nettoyez vos utilisations. Ne soyez pas négligés. Inspirer la confiance. Rendez votre code joli. Donnez à un autre dev cette sensation chaleureuse et floue.
Il n'y a pas de construction IL correspondant à using. Ainsi, les instructions using n'augmentent pas la mémoire de votre application car aucun code ni donnée ne sont générés à cet effet.
Using est utilisé lors de la compilation uniquement pour résoudre les noms de type abrégés en noms de type qualifiés. Ainsi, le seul effet négatif inutile que using puisse 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 pas inquiet à ce sujet cependant.
Ainsi, le seul effet négatif réel d'avoir des instructions using dont vous n'avez pas besoin est sur intellisense, car la liste des correspondances potentielles à compléter au fur et à mesure que vous tapez augmente.
Vous pouvez avoir 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, il s'agit généralement d'un problème mineur, détecté par le compilateur.
Laisser des directives extra using est acceptable. Il est utile de les supprimer, mais pas beaucoup. Par exemple, cela rend mes listes d'achèvement IntelliSense plus courtes et donc plus faciles à naviguer.
Les assemblys compilés ne sont pas affectés par les directives using superflues.
Parfois, je les mets dans un #region, et laissez-le effondré; cela rend le fichier un peu plus propre. OMI, c’est l’une des rares bonnes utilisations de #region.
Votre application n'utilisera pas plus de mémoire. Il appartient au compilateur de trouver les classes que vous utilisez dans les fichiers de code. Cela ne fait vraiment pas mal au-delà de ne pas être propre.
C'est la préférence personnelle principalement. Je les nettoie moi-même (Resharper me dit très bien qu’il est inutile d’utiliser des déclarations).
On pourrait dire que cela pourrait réduire le temps de compilation, mais avec la vitesse des ordinateurs et des compilateurs de nos jours, cela n’aurait aucun impact perceptible.
si vous voulez que votre code reste propre, les instructions non utilisées using doivent être supprimées du fichier. les avantages apparaissent très clairement lorsque vous travaillez dans une équipe collaborative qui doit comprendre votre code, pensez que tout votre code doit être maintenu, moins de code = moins de travail, les avantages sont à long terme.
L'instruction using vous empêche simplement de qualifier les types que vous utilisez. Personnellement, j'aime bien les nettoyer. Cela dépend vraiment de la façon dont une métrique de localisation est utilisée
Ils ne sont utilisés que comme raccourci. Par exemple, vous devrez écrire: System.Int32 à chaque fois si vous n’avez pas utilisé System; en haut.
Supprimer les codes inutilisés rend votre code plus propre.
Avoir uniquement les espaces de noms que vous utilisez réellement vous permet de garder votre code documenté.
Vous pouvez facilement trouver les parties de votre code qui s’appellent les unes des autres avec n’importe quel outil de recherche.
Si vous avez des espaces de noms inutilisés, cela ne signifie rien lorsque vous effectuez une recherche.
Je travaille actuellement à nettoyer les espaces de noms, 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 car l'accès aux données est séparé par des espaces de noms, par exemple. directement via une base de données et directement via un service Web.
Je ne peux pas penser à un moyen plus simple de faire tout cela à la fois.
Si vous voulez simplement que votre code soit une boîte noire (aux développeurs), alors oui, cela n'a pas d'importance. Mais si vous devez le conserver au fil du temps, il s'agit d'une documentation précieuse, comme tout autre code.
L'instruction 'using' n'affecte pas les performances car il ne s'agit que d'une aide à la qualification des noms de vos identifiants. Ainsi, au lieu de devoir taper, System.IO.Path.Combine (...), vous pouvez simplement taper, Path.Combine (...) si vous avez en utilisant System.IO.
N'oubliez pas que le compilateur fait beaucoup pour optimiser tout lors de la construction de votre projet. Utiliser cela est utilisé dans beaucoup d'endroits ou je ne devrais pas faire un différent une fois compilé.