Pourquoi supprimer les directives using inutilisées en C #?


120

Je me demande s'il y a des raisons (en dehors de la mise en ordre du code source) pour lesquelles les développeurs utilisent la fonctionnalité «Supprimer les inutilisés Usings» dans Visual Studio 2008?


Je crois que c'est une fonctionnalité de PowerCommands pour Visual Studio, pas de Visual Studio lui-même.
Hosam Aly

3
Dans VS2008, c'est certainement une fonctionnalité (avec la possibilité de trier les instructions d'utilisation) de VS lui-même.
Richard

1
@Hosam: PowerCommands vous permet de le faire pour l'ensemble du projet / solution. Faire cela par fichier est une fonctionnalité de VS lui-même.
configurateur

3
BTW, consultez Resharper si vous voulez un contrôle plus précis sur ce type de nettoyage.
John Feminella

2
En fait, je n'aime vraiment pas cette fonctionnalité - je me retrouve invariablement en train d'éditer un fichier et de devoir rajouter tous les espaces de noms système après que quelqu'un les ait nettoyés (généralement System, System.Collections.Generic et System.Linq.) Je trouve que cela ajoute plus de friction qu'il n'en économise. Maintenant, vos propres espaces de noms de projet plutôt que les espaces de noms de framework - ceux-ci ont plus de sens à nettoyer, pour clarifier le câblage de votre programme. Je souhaite qu'il y ait un moyen de permettre à VS de nettoyer les importations uniquement à partir de certains espaces de noms et de laisser ceux du système dont vous avez le plus souvent besoin.
user1454265

Réponses:


186

Il y a plusieurs raisons pour lesquelles vous voudriez les supprimer.

  • C'est inutile. Ils n'ajoutent aucune valeur.
  • C'est confu. Qu'est-ce qui est utilisé à partir de cet espace de noms?
  • Si vous ne le faites pas, vous accumulerez progressivement des usinginstructions inutiles à mesure que votre code évoluera au fil du temps.
  • L'analyse statique est plus lente.
  • La compilation du code est plus lente.

D'un autre côté, il n'y a pas beaucoup de raisons de les laisser. Je suppose que vous vous évitez de devoir les supprimer. Mais si vous êtes aussi paresseux, vous avez de plus gros problèmes!


59
Un bon programmeur EST paresseux, il maximise le travail à NE PAS faire. : D
Nicolas Dorier

34
Je ne suis pas d'accord pour dire qu'un bon programmeur est paresseux, mais je suis d'accord avec le sentiment de votre déclaration. Un bon programmeur les supprimera pour garder son code propre et éviter ainsi de futurs travaux / problèmes / problèmes pour lui-même et les autres.
Allan

2
Oui, c'est un excellent lien. Je suppose que mon argument était simplement que nous voulons "bon paresseux" plutôt que "mauvais paresseux"; ce dernier étant là où les programmeurs ne pouvaient pas être dérangés pour écrire du bon code.
Allan

5
Il est également intéressant de laisser les espaces de noms standard. Sur les grands projets et équipes, les laisser en place entraîne moins de conflits de fusion potentiels et moins de fichiers pour la révision du code. De plus, de nombreux développeurs ajoutent des méthodes d'extension déroutantes et difficiles à trouver, et parfois localiser les espaces de noms requis pour ces méthodes d'extension est un problème. Les nouveaux développeurs peuvent être habitués à avoir System.Linq, inclus dans leurs fichiers de code, et perdre beaucoup de temps à essayer de comprendre pourquoi certaines méthodes ne sont pas disponibles avant de demander de l'aide.
Mark At Ramp51

5
Vous voudrez peut-être en conserver certains pour empêcher l'intellisense d'être stupide dans le codage futur.
yazanpro

24

Je dirais bien au contraire - il est extrêmement utile de supprimer les instructions d'utilisation inutiles et inutiles.

Imaginez que vous deviez revenir à votre code dans 3, 6, 9 mois - ou quelqu'un d'autre doit reprendre votre code et le maintenir.

Si vous avez une longue liste d'instructions using qui ne sont pas vraiment nécessaires, regarder le code peut être assez déroutant. Pourquoi est-ce utilisé là-dedans, si rien n'est utilisé à partir de cet espace de noms?

Je suppose qu'en termes de maintenabilité à long terme dans un environnement professionnel, je suggérerais fortement de garder votre code aussi propre que possible - et cela inclut de vider des éléments inutiles. Moins d'encombrement signifie moins de confusion et donc une meilleure maintenabilité.

Marc


14

Cela me semble être une question très sensée, qui est traitée de manière assez désinvolte par les personnes qui y répondent.

Je dirais que toute modification du code source doit être justifiée. Ces changements peuvent avoir des coûts cachés et la personne qui pose la question a voulu en être informée. Ils n'ont pas demandé à être qualifiés de "paresseux", comme une personne inimitée.

Je viens de commencer à utiliser Resharper, et il commence à donner des avertissements et des conseils de style sur le projet dont je suis responsable. Parmi eux, il y a la suppression des directives utilisant redondantes, mais aussi des qualificatifs redondants, la capitalisation et bien d'autres. Mon instinct est de ranger le code et de résoudre tous les indices, mais mon chef d'entreprise me met en garde contre les changements injustifiés.

Nous utilisons un processus de construction automatisé, et par conséquent, toute modification de notre référentiel SVN générerait des changements que nous ne pourrions pas lier à des projets / bogues / problèmes, et déclencherait des versions et des versions automatisées qui n'apportaient aucun changement fonctionnel aux versions précédentes.

Si nous examinons la suppression des qualificatifs redondants, cela pourrait éventuellement semer la confusion chez les développeurs car les classes de nos couches Domaine et Données ne sont différenciées que par les qualificatifs.

Si je regarde la bonne utilisation de la capitalisation des anachronymes (c'est-à-dire ABCD -> Abcd), je dois prendre en compte que Resharper ne refactorise aucun des fichiers Xml que nous utilisons ces noms de classe de référence.

Donc, suivre ces conseils n'est pas aussi simple qu'il y paraît, et doit être traité avec respect.


6
Bon point, mais vous ne devez pas oublier que le maintien d'un code simple et propre améliore la maintenabilité, ce qui est également un objectif commercial. Vous devez peser les deux. Idéalement, vous voulez faire ce genre de refactorisations juste après une sortie afin que vous puissiez avoir une ardoise aussi propre que possible pour commencer une nouvelle et avoir suffisamment de temps pour attraper les régressions éventuelles.
David Reis

14

En plus des raisons déjà données, il évite les conflits de noms inutiles. Considérez ce fichier:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

Ce code ne se compile pas car les espaces de noms System.IO et System.Windows.Shapes contiennent chacun une classe appelée Path. Nous pourrions le réparer en utilisant le chemin complet de la classe,

        private static string temporaryPath = System.IO.Path.GetTempFileName();

ou nous pourrions simplement supprimer la ligne using System.Windows.Shapes;.


13

Moins d'options dans la fenêtre contextuelle Intellisense (en particulier si les espaces de noms contiennent de nombreuses méthodes d'extension).

En théorie, Intellisense devrait également être plus rapide.


1
+1 pour intellisense. C'est en fait lent au démarrage (je vois régulièrement "Construire le cache, réessayer plus tard"), donc cela peut être en fait significatif. Compilez le temps dont tout le monde parle ... je n'ai pas encore vu de chiffres.
Luc

5

Retirez-les. Moins de code à regarder et à s'interroger économise du temps et de la confusion. Je souhaite que plus de gens gardent les choses simples, propres et ordonnées. C'est comme avoir des chemises et des pantalons sales dans votre chambre. C'est moche et il faut se demander pourquoi c'est là.


4

Cela permet également d'éviter les fausses dépendances circulaires, en supposant que vous puissiez également supprimer certaines références dll / projet de votre projet après avoir supprimé les utilisations inutilisées.


3

Le code se compile plus rapidement.


5
Vous avez des preuves à l'appui?
cjk

14
Oh CK - tu m'as encore rattrapé. J'ai menti. La suppression du texte inutile ralentit la compilation du code. Pensez-y :)
Compte mort

@ck: J'ai vérifié que la suppression des instructions using inutilisées d'un projet au travail améliorait considérablement le temps de compilation. Bien sûr, ce serait - moins d'octets à lire sur le disque dur.
configurateur

19
Ce serait bien de voir de vraies statistiques. Si nous économisons seulement quelques millisecondes lors de la compilation, la vitesse n'est pas un argument convaincant. Cependant, il existe d'autres raisons de supprimer les instructions using inutiles.
Greg

3
Il ne s'agit pas de mentir ou pas. Toute personne sensée devinerait que moins d'encombrement signifie plus d'efficacité. La "preuve" pour le sauvegarder est de fournir une valeur à votre réponse et de soutenir l'argument selon lequel "plus rapide" ne signifie pas seulement quelques ms, mais en fait une expérience améliorée pour compiler plus rapidement votre projet.
Matheus Felipe

3

Récemment, j'ai eu une autre raison pour laquelle la suppression des importations inutilisées est très utile et importante.

Imaginez que vous ayez deux assemblys, où l'un référence l'autre (pour l'instant appelons le premier Aet le référencé B). Maintenant, quand vous avez du code dans A qui dépend de B, tout va bien. Cependant, à un certain stade de votre processus de développement, vous remarquez que vous n'avez plus besoin de ce code, mais vous laissez l'instruction using où elle se trouvait. Maintenant, vous avez non seulement une usingdirective vide de sens, mais aussi une référence d' assembly à Blaquelle n'est utilisée nulle part, mais dans la directive obsolète. Cela augmente tout d'abord le temps nécessaire à la compilation A, car il Bdoit également être chargé.

Il ne s'agit donc pas seulement d'un problème de code plus propre et plus facile à lire, mais également de gestion des références d'assembly dans le code de production où tous ces assemblys référencés n'existent même pas .

Enfin, dans notre exemple, nous avons dû expédier B et A ensemble, bien que B ne soit utilisé nulle part dans A mais dans la section using. Cela affectera massivement l' exécution -performance de Alors du chargement de l'ensemble.


2

Au moins en théorie, si vous avez reçu un fichier C # .cs (ou n'importe quel fichier de code source de programme unique), vous devriez être en mesure de regarder le code et de créer un environnement qui simule tout ce dont il a besoin. Avec une technique de compilation / analyse, vous pouvez même créer un outil pour le faire automatiquement. Si cela est fait par vous au moins à l'esprit, vous pouvez vous assurer de comprendre tout ce que dit le fichier de code.

Considérez maintenant, si vous avez reçu un fichier .cs avec 1000 usingdirectives dont seulement 10 ont été réellement utilisées. Chaque fois que vous regardez un symbole nouvellement introduit dans le code qui fait référence au monde extérieur, vous devrez parcourir ces 1000 lignes pour comprendre de quoi il s'agit. Cela ralentit évidemment la procédure ci-dessus. Donc, si vous pouvez les réduire à 10, cela vous aidera!

À mon avis, la usingdirective C # est très très faible, car vous ne pouvez pas spécifier un seul symbole générique sans perdre la généricité, et vous ne pouvez pas utiliser la usingdirective alias pour utiliser des méthodes d'extension. Ce n'est pas le cas dans d'autres langages comme Java, Python et Haskell, dans ces langages vous pouvez spécifier (presque) exactement ce que vous voulez du monde extérieur. Mais événement alors, je suggérerai d'utiliser l' usingalias chaque fois que possible.

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.