Perché non dovrei usare sempre i tipi nullable in C#

Question

Ho cercato delle indicazioni su questo perché il concetto è stato introdotto in .net 2.0.

Perché dovrei voler utilizzare tipi di dati non annullabili in C#? (Una domanda migliore è perché non scegliere i tipi annullabili per impostazione predefinita e utilizzare solo tipi non annullabili quando ciò ha un significato esplicito.)

C'è un colpo "significativo" alle prestazioni nella scelta di un tipo di dati nullable su peer non annullabile?

Preferisco di gran lunga controllare i miei valori rispetto a null anziché Guid.empty, string.empty, DateTime.MinValue, < = 0, ecc. E per lavorare con i tipi nullable in generale. E l'unica ragione per cui non scelgo più spesso i tipi nullable è la sensazione di prurito nella parte posteriore della mia testa che mi fa pensare che sia più che retrocompatibile che costringe quel qualcosa in più '?' carattere per consentire esplicitamente un valore nullo.

C'è qualcuno là fuori che sempre (quasi sempre) sceglie tipi nullable anziché tipi non annullibili?

Grazie per il vostro tempo,

Answer 1

Il motivo per cui non si dovrebbe usare sempre tipi nullable è che a volte si è in grado di garantire che un valore sarà inizializzato. E dovresti provare a progettare il tuo codice in modo che questo avvenga il più spesso possibile. Se non è possibile che un valore possa essere non inizializzato, non c'è motivo per cui null dovrebbe essere un valore legale per esso. Come un esempio molto semplice, si consideri questo:

List<int> list = new List<int>() 
int c = list.Count; 

Questo è sempre valido. Non esiste alcun modo in cui c potrebbe essere non inizializzato. Se è stato trasformato in un int?, si potrebbe effettivamente dire ai lettori del codice "questo valore potrebbe essere nullo. Assicurati di controllare prima di usarlo". Ma sappiamo che questo non può mai accadere, quindi perché non esporre questa garanzia nel codice?

Hai perfettamente ragione nei casi in cui un valore è facoltativo. Se abbiamo una funzione che può o non può restituire una stringa, restituire null. Non restituire string.Empty(). Non restituire "valori magici".

Ma non tutti i valori sono opzionali. E rendere tutto facoltativo rende il resto del codice molto più complicato (aggiunge un altro percorso di codice che deve essere gestito).

Se è possibile garantire espressamente che questo valore sarà sempre valido, allora perché buttare via queste informazioni? Questo è quello che fai rendendolo un tipo nullable. Ora il valore può o non può esistere e chiunque utilizzi il valore dovrà gestire entrambi i casi. Ma tu sai che solo uno di questi casi è possibile in primo luogo. Così gli utenti del tuo codice sono un favore e riflettono questo fatto nel tuo codice. Qualsiasi utente del tuo codice può quindi fare affidamento sul fatto che il valore sia valido e deve gestire solo un singolo caso piuttosto che due.

Answer 2

perché è scomodo dover sempre controllare se il tipo nullable è null.

Ovviamente ci sono situazioni in cui un valore è veramente opzionale, e in quei casi ha senso usare un tipo nullable piuttosto che numeri magici, ecc, ma dove possibile proverei ad evitarli.

// nice and simple, this will always work 
int a = myInt; 

// compiler won't let you do this 
int b = myNullableInt; 

// compiler allows these, but causes runtime error if myNullableInt is null 
int c = (int)myNullableInt; 
int d = myNullableInt.Value;  

// instead you need to do something like these, cumbersome and less readable 
int e = myNullableInt ?? defaultValue; 
int f = myNullableInt.HasValue ? myNullableInt : GetValueFromSomewhere(); 

Answer 3

Io tendo ad usare i tipi Nullable ovunque hanno un senso - non mi preoccupano le prestazioni fino a che non è un problema, allora io preparo le poche aree in cui è e da fare con esso.

Tuttavia, trovo anche che, in generale, la maggior parte dei miei valori finisce per essere non annullabile. In effetti, ci sono molte volte che mi piacerebbe davvero un NotNullable che posso usare con i tipi di riferimento per scoprire un problema nullo quando ottengo il null, non più tardi quando provo ad usarlo.

Answer 4

Penso che i progettisti linguistici ritengano che "i tipi di riferimento siano annullabili per impostazione predefinita" sia stato un errore e che il non nullable sia l'unico valore predefinito valido e che sia necessario attivare la nullità. (Questo è come è in molti moderni linguaggi funzionali.) "Null" è di solito un mucchio di problemi.

Answer 5

Lei sembra avere 2 domande differenti ...

Perché mai dovrei voler utilizzare i tipi di dati non-nullable in C#?

Semplice, perché i dati di tipo valore su cui si basa è garantito dal compilatore per avere effettivamente un valore!

Perché non scegliere i tipi nullable per impostazione predefinita e utilizzare solo tipi non annullibili quando ciò ha un significato esplicito?

Come già detto da Joel, un tipo può essere nullo solo se si tratta di un tipo di riferimento. I tipi di valore sono garantiti dal compilatore per avere un valore. Se il tuo programma dipende da una variabile per avere un valore, allora questo è il comportamento che vorresti non scegliendo un tipo nullable.

Ovviamente, quando i tuoi dati provengono da qualsiasi luogo diverso dal tuo programma, tutte le scommesse sono disattivate. Il miglior esempio è da un database. I campi del database possono essere null, quindi è preferibile che la variabile del programma imiti questo valore, non solo creare un valore "magico" (vale a dire -1, 0 o qualsiasi altra cosa) che "rappresenta" null. Lo fai con tipi nullable.

Answer 6

Anche se i valori nulli possono essere conveniente per l'utilizzo come "non-inizializzato-ancora" o "non specificato" valori, rendono il codice più complesso, soprattutto perché si sta sovraccaricando il significato di null così come la variabile (numero-o-nullo vs. solo-un-numero).

I valori NULL sono preferiti da molti progettisti di database e programmatori di database SQL ma con un piccolo cambiamento nel pensare al problema è possibile eliminare valori nulli e in realtà avere un codice più semplice e più affidabile (ad esempio, non preoccuparsi di NullReferenceException s) .

C'è in realtà una grande richiesta per un "T!" operatore che rende qualsiasi tipo di riferimento non annullabile, simile a come "T?" rende nullable i tipi di valore, e Anders Hejlsberg, l'inventore di C#, ha voluto che avesse incluso l'abilità.

Vedi anche la questione, Why is “null” present in C# and java?

Answer 7

L'unica volta che un tipo Nullable deve mai essere utilizzato, è nel caso in cui un determinato campo in una tabella del database richiede assolutamente che un null venga inviato o ricevuto dall'applicazione a un certo punto. Anche in questo caso, si dovrebbe sempre cercare di trovare un modo per utilizzare il tipo Nullable. Bool non è sempre il tuo migliore amico.