Perché rimuovere le direttive using inutilizzate in C #?

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?

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!

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

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.

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;.

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

Teoricamente anche Intellisense dovrebbe essere più veloce.

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ì.

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.

Il codice viene compilato più velocemente.

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.

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.