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?
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?
Risposte:
Ci sono alcuni motivi per cui vorresti eliminarli.
using
dichiarazioni inutili man mano che il tuo codice cambia nel tempo.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ì.
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 A
e 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 B
cui non è usato da nessuna parte ma nella direttiva obsoleta. Questo in primo luogo aumenta la quantità di tempo necessaria per la compilazione A
, poiché B
deve 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 using
sezione-. 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 using
direttiva C # è molto molto debole, poiché non è possibile specificare un singolo simbolo generico senza perdere la genericità e non è possibile utilizzare la using
direttiva 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' using
alias quando possibile.