Quelles sont les conséquences d'avoir des références et des utilisations inutiles?

12

Je suis un peu bizarre et j'ai tendance à garder mes projets en nettoyant les références et les usings dans chaque classe pour ne garder que ce qui est réellement utilisé.

Quel autre argument pourrais-je faire (en plus de calmer mon nerf de TOC) pour garder l'essentiel? Je pense principalement aux références système, toute référence à un travail personnalisé apportera son lot de problèmes de compatibilité descendante. L'empreinte de la version est-elle plus importante? Compiler le temps plus longtemps?

c#

— MPelletier
source

5

Notez que usings et références ne sont pas la même chose. Beaucoup de réponses ne tiennent pas compte de cela.

— phoog

1

Si vous souhaitez garder le code propre et l'utiliser au minimum, pensez à acheter ReSharper. Extension étonnante à Visual Studio. Je ne peux pas vivre / programmer sans. ;-)

— Anders

1

stackoverflow.com/q/136278/3370168

— azam

13

Intellisense vous sera beaucoup plus utile si vous gardez usingau minimum, et c'est un grand avantage.

A part ça, je ne pense pas qu'il y ait de gain. Alors peut-être que le compilateur C # fonctionnera plus rapidement de, disons, 1%; et alors.

— Mike Nakis
source

1

La valeur cumulée de ce 1% est considérable ... mais fondamentalement, vous vous attendez à ce que le compilateur optimise tout problème. Cependant, je n'ai aucun problème à être simplement rangé

— Murph

C # IntelliSense a été un peu désordonné de toute façon depuis environ 2005, quand ils ont commencé à tout déverser dans la liste.

— Rei Miyasaka

@ReiMiyasaka pour que vous obteniez IntelliSense pour tout ce que vous voulez, puis faites Ctrl+.une correction rapide "Ajouter un espace de noms XYZ"

— kizzx2

1

@Murph: quelle que soit la valeur cumulée de 1%, elle restera toujours 1% du total cumulé, donc ce sera toujours sans conséquence. En outre, le compilateur ne peut ignorer aucun usings jusqu'à ce qu'il ait compris qu'ils sont en fait inutiles, mais il ne peut le comprendre que s'il a d'abord compilé votre fichier source entier. Comme pour les références de projet, elles ne sont pas supprimées simplement parce qu'elles ne semblent pas être utilisées, car elles peuvent être utilisées de manière dynamique (non détectable au moment de la compilation).

— Mike Nakis

1

Un peu tard, mais dans mon cas, nous créons une application pour un appareil à ressources très limitées. L'ajout de références inutiles aura un impact sur la taille finale de l'application. Et bien, nous essaierons de distribuer le package et de rivaliser avec d'autres packages, un package plus gros peut faire réfléchir à deux fois l'utilisateur sur le fait de télécharger ou non l'application.

— hmadrigal

9

Puisqu'il est pratiquement trivial d'accomplir cela dans Visual Studio (simple clic droit), pourquoi ne pas le faire?

Ceci est cohérent avec le rasoir d' Occam , c'est tout simplement une bonne ingénierie.

En ce qui concerne les conséquences de ne pas le faire, réfléchissez à ce qui se passe si un autre développeur essaie d'ouvrir votre projet et qu'il contient une référence (inutilisée) à une bibliothèque qu'il / elle n'a pas sur son ordinateur. Maintenant, ce pauvre développeur doit comprendre pourquoi cette référence non résolue existe et que faire à ce sujet.

Si vous préférez, considérez-le en termes de règle d'or. Souhaitez-vous reprendre le développement d'un projet comportant de nombreuses références à des bibliothèques que vous n'aviez pas sur votre ordinateur et que vous ne saviez pas pourquoi elles sont là?

— JonnyBoats
source

+1, un complément peut le faire pour l'ensemble de la solution. Cela m'a également rappelé la vidéo ClojureScript et Google Closure où l'optimisation de l'ensemble du programme est importante car une page Web typique fait maintenant environ 1 Mo. C'est une bonne habitude d'avoir - de nettoyer les choses qui ne sont pas nécessaires.

— Job

6

usingles instructions sont simplement pour que le compilateur puisse référencer complètement les classes, etc. Les usinginstructions supplémentaires n'auront aucun effet appréciable sur le temps de compilation.

De plus, le runtime ne chargera pas un assembly référencé jusqu'à ce qu'il soit réellement nécessaire, donc encore une fois, je ne pense pas qu'il y ait de conséquences négatives des références inutiles.

Si vous utilisez un outil comme Reflector, la recherche et la suppression de ces bits inutiles peuvent être principalement automatisées, donc je dirais que c'est inutile de consacrer beaucoup de temps à ces activités. Par exemple, une heure ou deux de suppression manuelle des usingrelevés inutiles est plus que payante pour une licence Reflector - et il est livré avec de nombreuses autres fonctionnalités améliorant la productivité.

— quentin-starin
source

Le nettoyage à l'aide de est une fonction intégrée de VS 2010 (je pense que 2008 aussi). Et ReSharper peut également faire les références. Mais oui, avant de me lancer dans un nettoyage à grande échelle, je chercherais à utiliser un outil pour le faire pour moi.

— MPelletier

+1 pour exprimer clairement la distinction entre les usingréférences non utilisées et les références non utilisées. Les deux sont très différents!

— phoog

1

En plus de ce qui précède, je suppose qu'il n'a pas encore été mentionné ici que, chaque référence nécessite un composant dans le cadre .NET ou une DLL externe. Si la référence est faite à une DLL externe, vous devrez l'avoir quand (et où) vous exécuterez le logiciel.

Modifier - Selon le commentaire valide de phoog ci-dessous: L'application fonctionnerait toujours si la DLL n'est pas utilisée et n'est pas requise pour être livrée avec l'application simplement parce qu'elle a été ajoutée aux références. Pour prendre soin des références non utilisées dans le code, vous pouvez consulter: Suppression des références inutilisées .

— Aucune chance
source

1

Si la référence n'est pas utilisée, vous n'aurez pas besoin de la DLL quand et où vous exécuterez le logiciel.

— phoog

@phoog, merci pour votre commentaire. Au moins dans .NET VS2010, si vous ajoutez manuellement une référence à la solution, la DLL est physiquement ajoutée au dossier bin même si vous ne l'utilisez pas dans le code.

— NoChance

1

Mais, si vous supprimez la DLL du dossier bin ou publiez l'application sans la DLL, l'application doit quand même s'exécuter.

— phoog

@phoog, vous avez raison, merci de l'avoir signalé. Je vais modifier le message.

— NoChance