C'è qualche svantaggio nelle qualificazioni ridondanti?Qualche vantaggio?

Question

Ad esempio, fare riferimento a qualcosa come System.Data.Datagrid anziché solo Datagrid.Si prega di fornire esempi e spiegazioni.Grazie.

Answer 1

Il vantaggio è che non è necessario aggiungere un'importazione per tutto ciò che usi, soprattutto se è l'unica cosa che usi da un particolare spazio dei nomi, inoltre previene le collisioni.

Lo svantaggio, ovviamente, è che il codice aumenta di dimensioni e diventa più difficile da leggere quanto più si utilizzano qualificatori specifici.

Personalmente tendo a utilizzare le importazioni per la maggior parte delle cose a meno che non sappia con certezza che utilizzerò qualcosa da un particolare spazio dei nomi solo una o due volte, quindi non avrà alcun impatto sulla leggibilità del mio codice.

Answer 2

Sei molto esplicito riguardo al tipo a cui fai riferimento e questo è un vantaggio.Tuttavia, nello stesso processo stai rinunciando alla chiarezza del codice, il che è chiaramente uno svantaggio nel mio caso, poiché voglio che il codice sia leggibile e comprensibile.Scelgo la versione breve a meno che non abbia un conflitto in diversi namespace che può essere risolto solo con il riferimento esplicito alle classi.A meno che non ne crei un alias con la parola chiave utilizzando:

using Datagrid = System.Data.Datagrid;

Answer 3

In realtà il percorso completo lo è global::System.Data.DataGrid.Lo scopo di utilizzare un percorso più qualificato è evitare di dover utilizzare istruzioni using aggiuntive, soprattutto se l'introduzione di un altro using causerà problemi con la risoluzione del tipo.Esistono identificatori più completi in modo da poter essere espliciti quando è necessario esserlo, ma se lo spazio dei nomi della classe è chiaro, allora DataGrid la versione è più chiara per molti.

Answer 4

Generalmente utilizzo la forma più breve disponibile per mantenere il codice il più pulito e leggibile possibile.Dopotutto, è a questo che servono le direttive using, e i tooltip nell'editor VS ti forniscono dettagli immediati sulla provenienza di un tipo.

Tendo anche a utilizzare un tag namespace per RCW in uno strato di interoperabilità COM, per richiamare esplicitamente tali variabili nel codice (potrebbero richiedere un'attenzione speciale sul ciclo di vita e sulla raccolta), ad es.

using _Interop = Some.Interop.Namespace;

Answer 5

In termini di prestazioni non ci sono vantaggi/svantaggi.Tutto viene risolto in fase di compilazione e l'MSIL generato è identico indipendentemente dal fatto che si utilizzino nomi completi o meno.

Il motivo per cui il suo utilizzo è prevalente nel mondo .NET è dovuto al codice generato automaticamente, come il markup del designer.In tal caso sarebbe meglio qualificare completamente i nomi come i nomi delle classi a causa di possibili conflitti con altre classi che potresti avere nel tuo codice.

Se disponi di uno strumento come ReSharper, ti dirà effettivamente quali riferimenti completi non sono necessari (ad es.oscurandoli) in modo da poterli tagliare.Se esegui spesso il copia-incolla del codice tra le varie basi di codice, sarebbe necessario qualificarle completamente.(poi ancora, perché dovresti voler fare taglia-incolla tutto il tempo;è una cattiva forma di riutilizzo del codice!)

Answer 6

Non penso che ci sia davvero uno svantaggio, solo leggibilità rispetto al tempo effettivo impiegato nella codifica.In generale se non hai spazi dei nomi con oggetto ambiguo non penso che sia realmente necessario.Un'altra cosa da considerare è il livello di utilizzo.Se disponi di un metodo che utilizza la riflessione e sei d'accordo nel digitare System.Reflection 10 volte, allora non è un grosso problema, ma se prevedi di utilizzare molto uno spazio dei nomi, consiglierei un'inclusione.

Answer 7

A seconda della situazione, i qualificatori aggiuntivi genereranno un avviso (se questo è ciò che intendi per ridondante).Se poi tratti gli avvisi come errori, questo è uno svantaggio piuttosto serio.

Mi sono imbattuto in questo con GCC, ad esempio.

struct A {
    int A::b; // warning!
}