Perché rimuovere le direttive using inutilizzate in C #?


120

Mi chiedo se ci sono ragioni (oltre a riordinare il codice sorgente) per cui gli sviluppatori utilizzano la funzionalità "Rimuovi inutilizzati Usings" in Visual Studio 2008?


Credo che sia una caratteristica di PowerCommands per Visual Studio, non di Visual Studio stesso.
Hosam Aly

3
In VS2008 è certamente una caratteristica (insieme alla capacità di ordinare le istruzioni using) di VS stesso.
Richard

1
@Hosam: PowerCommands ti consente di farlo per l'intero progetto / soluzione. Farlo per file è una caratteristica di VS stesso.
configuratore

3
BTW, controlla Resharper se desideri un controllo più preciso su questo tipo di pulizia.
John Feminella

2
In realtà non mi piace davvero questa funzione: mi ritrovo invariabilmente a modificare un file e dover aggiungere nuovamente tutti gli spazi dei nomi di sistema dopo che qualcuno li ha ripuliti (di solito System, System.Collections.Generic e System.Linq.) Trovo che aggiunge più attrito di quanto si risparmia. Ora, i tuoi spazi dei nomi del progetto piuttosto che gli spazi dei nomi del framework - quelli hanno più senso da pulire, per chiarire il cablaggio del tuo programma. Vorrei che ci fosse un modo per avere VS ripulire le importazioni solo da determinati spazi dei nomi e lasciare quelli di sistema di cui hai più bisogno.
user1454265

Risposte:


186

Ci sono alcuni motivi per cui vorresti eliminarli.

  • È inutile. Non aggiungono valore.
  • È confusionario. Cosa viene utilizzato da quello spazio dei nomi?
  • In caso contrario, accumulerai gradualmente usingdichiarazioni inutili man mano che il tuo codice cambia nel tempo.
  • L'analisi statica è più lenta.
  • La compilazione del codice è più lenta.

D'altra parte, non ci sono molte ragioni per lasciarli dentro. Suppongo che ti risparmi lo sforzo di doverli cancellare. Ma se sei così pigro, hai problemi più grandi!


59
Un buon programmatore è pigro, massimizza il lavoro per NON farlo. : D
Nicolas Dorier

34
Non sono d'accordo che un buon programmatore sia pigro, ma concordo con il sentimento della tua dichiarazione. Un buon programmatore li cancellerà per mantenere pulito il suo codice e quindi evitare lavori / problemi / problemi futuri per sé e per gli altri.
Allan

2
Bene, questo è un ottimo collegamento. Immagino che il mio punto fosse solo che vogliamo "bravo pigro" piuttosto che "cattivo pigro"; quest'ultimo è dove i programmatori non potevano essere disturbati a scrivere un buon codice.
Allan

5
C'è anche il merito di lasciare spazi dei nomi standard. Su grandi progetti e team, lasciandoli in risultati in meno potenziali conflitti di unione e meno file per la revisione del codice. Inoltre, molti sviluppatori aggiungono metodi di estensione confusi e difficili da trovare alle cose e talvolta individuare gli spazi dei nomi richiesti per questi metodi di estensione è una seccatura. I nuovi sviluppatori potrebbero essere abituati ad avere System.Linq, incluso nei loro file di codice, e perdere molto tempo a cercare di capire perché alcuni metodi non sono disponibili prima di chiedere aiuto.
Mark At Ramp51

5
Potresti volerne tenere alcuni per evitare che l'intellisense diventi stupido come l'inferno nella programmazione futura.
yazanpro

24

Direi al contrario: è estremamente utile rimuovere le istruzioni using non necessarie e non necessarie.

Immagina di dover tornare al tuo codice in 3, 6, 9 mesi o che qualcun altro debba prendere il controllo del tuo codice e mantenerlo.

Se hai una lunga lista di istruzioni d'uso che non sono realmente necessarie, guardare il codice potrebbe creare confusione. Perché viene utilizzato lì, se non viene utilizzato nulla da quello spazio dei nomi ??

Immagino che in termini di manutenibilità a lungo termine in un ambiente professionale, suggerirei caldamente di mantenere il codice il più pulito possibile - e questo include lo scarico di cose non necessarie da esso. Meno disordine equivale a meno confusione e quindi maggiore manutenibilità.

Marc


14

Questa mi sembra una domanda molto sensata, che viene trattata in modo piuttosto impertinente dalle persone che rispondono.

Direi che qualsiasi modifica al codice sorgente deve essere giustificata. Questi cambiamenti possono avere costi nascosti e la persona che pone la domanda voleva esserne consapevole. Non hanno chiesto di essere chiamati "pigri", come una persona inimata.

Ho appena iniziato a usare Resharper e sta iniziando a dare avvertimenti e suggerimenti di stile sul progetto di cui sono responsabile. Tra questi vi è la rimozione della direttiva sull'utilizzo ridondante, ma anche di qualificazioni ridondanti, capitalizzazione e molti altri. Il mio istinto è quello di riordinare il codice e risolvere tutti i suggerimenti, ma la mia testa aziendale mi mette in guardia contro modifiche ingiustificate.

Utilizziamo un processo di compilazione automatizzato e quindi qualsiasi modifica al nostro repository SVN genererebbe modifiche che non potremmo collegare a progetti / bug / problemi e attiverebbe build e rilasci automatizzati che non hanno fornito modifiche funzionali alle versioni precedenti.

Se guardiamo alla rimozione dei qualificatori ridondanti, ciò potrebbe causare confusione agli sviluppatori poiché le classi dei nostri livelli di dominio e dati sono differenziate solo dai qualificatori.

Se guardo l'uso corretto delle maiuscole degli anacronimi (cioè ABCD -> Abcd), devo tenere in considerazione che Resharper non effettua il refactoring di nessuno dei file Xml che utilizziamo per i nomi delle classi di riferimento.

Quindi, seguire questi suggerimenti non è così semplice come sembra e dovrebbe essere trattato con rispetto.


6
Buon punto, ma non dovresti anche dimenticare che mantenere un codice pulito e semplice migliora la manutenibilità, che è anche un obiettivo aziendale. Devi pesare entrambi. Idealmente si desidera eseguire questo tipo di refactoring subito dopo un rilascio in modo da poter disporre di uno slate il più pulito possibile per iniziarne uno nuovo e avere tutto il tempo per catturare eventuali regressioni.
David Reis,

14

Oltre alle ragioni già fornite, impedisce conflitti di denominazione non necessari. Considera questo file:

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

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

Questo codice non viene compilato perché entrambi gli spazi dei nomi System.IO e System.Windows.Shapes contengono ciascuno una classe denominata Path. Potremmo risolverlo utilizzando il percorso di classe completo,

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

o potremmo semplicemente rimuovere la linea using System.Windows.Shapes;.


13

Meno opzioni nel popup Intellisense (in particolare se gli spazi dei nomi contengono molti metodi di estensione).

Teoricamente anche Intellisense dovrebbe essere più veloce.


1
+1 per intellisense. In realtà è lento all'avvio (vedo regolarmente "Creazione della cache, riprova più tardi"), quindi questo potrebbe essere effettivamente significativo. Compilare il tempo di cui parlano tutti gli altri ... devo ancora vedere i numeri.
Luc

5

Rimuovili. Meno codice da guardare e di cui interrogarsi fa risparmiare tempo e confusione. Vorrei che più persone TENERO LE COSE SEMPLICI, BENE e IN ORDINE. È come avere camicie e pantaloni sporchi in camera tua. È brutto e devi chiederti perché è lì.


4

Aiuta anche a prevenire false dipendenze circolari, supponendo che tu sia anche in grado di rimuovere alcuni riferimenti dll / progetto dal tuo progetto dopo aver rimosso gli utilizzi inutilizzati.


3

Il codice viene compilato più velocemente.


5
Hai qualche prova a sostegno di ciò?
cjk

14
Oh CK - mi hai beccato di nuovo. Ho mentito. La rimozione del testo non necessario rende effettivamente la compilazione del codice più lenta. Pensaci :)
Account morto il

@ck: ho verificato che la rimozione di istruzioni using inutilizzate da un progetto al lavoro ha migliorato i tempi di compilazione di una quantità notevole. Ovviamente sarebbe - meno byte da leggere dal disco rigido.
configuratore

19
Sarebbe bello vedere alcune statistiche reali. Se stiamo risparmiando solo pochi millisecondi durante la compilazione, la velocità non è un argomento convincente. Tuttavia, ci sono altri motivi per rimuovere le istruzioni using non necessarie.
Greg

3
Non si tratta di mentire o no. Qualsiasi persona ragionevole supporrebbe che meno disordine significhi più efficienza. La "prova" per sostenerlo è fornire valore alla tua risposta e supportare l'argomento che "più veloce" non significa solo pochi ms, ma in realtà un'esperienza migliorata per compilare più velocemente il tuo progetto.
Matheus Felipe

3

Recentemente ho un altro motivo per cui l'eliminazione delle importazioni inutilizzate è piuttosto utile e importante.

Immagina di avere due assembly, in cui uno fa riferimento all'altro (per ora chiamiamo il primo Ae il referenziato B). Ora, quando hai un codice in A che dipende da B, tutto va bene. Tuttavia, a un certo punto del processo di sviluppo, noti che in realtà non hai più bisogno di quel codice, ma lasci l'istruzione using dov'era. Ora non solo hai una using-direttiva priva di significato ma anche un riferimento ad un assembly a Bcui non è usato da nessuna parte ma nella direttiva obsoleta. Questo in primo luogo aumenta la quantità di tempo necessaria per la compilazione A, poiché Bdeve essere caricata anche.

Quindi questo non è solo un problema di codice più pulito e più facile da leggere, ma anche di mantenere i riferimenti agli assembly nel codice di produzione dove non esistono nemmeno tutti gli assembly a cui si fa riferimento .

Infine nel nostro esempio abbiamo dovuto spedire B e A insieme, sebbene B non sia usato da nessuna parte in A ma nella usingsezione-. Ciò influenzerà notevolmente le prestazioni di runtimeA durante il caricamento dell'assembly.


2

Almeno in teoria, se ti è stato fornito un file C # .cs (o un singolo file di codice sorgente del programma), dovresti essere in grado di guardare il codice e creare un ambiente che simuli tutto ciò di cui ha bisogno. Con alcune tecniche di compilazione / analisi potresti persino creare uno strumento per farlo automaticamente. Se questo viene fatto almeno da te, puoi assicurarti di aver compreso tutto ciò che dice il file di codice.

Ora considera, se ti è stato dato un file .cs con 1000 using direttive, solo 10 sono state effettivamente utilizzate. Ogni volta che guardi un simbolo che è stato introdotto di recente nel codice che fa riferimento al mondo esterno, dovrai passare attraverso quelle 1000 righe per capire di cosa si tratta. Questo ovviamente rallenta la procedura di cui sopra. Quindi, se puoi ridurli a 10, sarà d'aiuto!

A mio parere, la usingdirettiva C # è molto molto debole, poiché non è possibile specificare un singolo simbolo generico senza perdere la genericità e non è possibile utilizzare la usingdirettiva alias per utilizzare metodi di estensione. Questo non è il caso in altri linguaggi come Java, Python e Haskell, in quei linguaggi sei in grado di specificare (quasi) esattamente quello che vuoi dal mondo esterno. Ma poi, suggerirò di usare l' usingalias quando possibile.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.