Quale è preferito: Nullable <T> .HasValue o Nullable <T>! = Null?

Ho sempre usato Nullable<>.HasValueperché mi piaceva la semantica. Tuttavia, recentemente stavo lavorando sulla base di codice esistente di qualcun altro, che Nullable<> != nullinvece utilizzava esclusivamente.

C'è un motivo per usare l'uno sull'altro o è puramente una preferenza?

1. int? a;
   if (a.HasValue)
       // ...

vs.

2. int? b;
   if (b != null)
       // ...

Il compilatore sostituisce i confronti null con una chiamata a HasValue, quindi non vi è alcuna differenza reale. Fai quello che è più leggibile / ha più senso per te e i tuoi colleghi.

Preferisco (a != null)che la sintassi corrisponda ai tipi di riferimento.

Ho fatto qualche ricerca su questo usando diversi metodi per assegnare valori a un int nullabile. Ecco cosa è successo quando ho fatto varie cose. Dovrebbe chiarire cosa sta succedendo. Ricorda: Nullable<something>o la stenografia something?è una struttura per la quale il compilatore sembra fare molto lavoro per farci usare con null come se fosse una classe.
Come si vedrà di seguito, SomeNullable == nulle SomeNullable.HasValuesarà sempre restituire un atteso vero o falso. Anche se non dimostrato di seguito, SomeNullable == 3è valido anche (supponendo che SomeNullable sia un int?).
Mentre SomeNullable.Valueci viene assegnato un errore di runtime se assegnato nulla SomeNullable. Questo è in effetti l'unico caso in cui nullable potrebbe causarci un problema, grazie a una combinazione di operatori sovraccarichi, sovraccarichiobject.Equals(obj) metodo, ottimizzazione del compilatore e business delle scimmie.

Ecco una descrizione di alcuni codici che ho eseguito e quale output ha prodotto nelle etichette:

int? val = null;
lbl_Val.Text = val.ToString(); //Produced an empty string.
lbl_ValVal.Text = val.Value.ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValEqNull.Text = (val == null).ToString(); //Produced "True" (without the quotes)
lbl_ValNEqNull.Text = (val != null).ToString(); //Produced "False"
lbl_ValHasVal.Text = val.HasValue.ToString(); //Produced "False"
lbl_NValHasVal.Text = (!(val.HasValue)).ToString(); //Produced "True"
lbl_ValValEqNull.Text = (val.Value == null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValValNEqNull.Text = (val.Value != null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")

Ok, proviamo il prossimo metodo di inizializzazione:

int? val = new int?();
lbl_Val.Text = val.ToString(); //Produced an empty string.
lbl_ValVal.Text = val.Value.ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValEqNull.Text = (val == null).ToString(); //Produced "True" (without the quotes)
lbl_ValNEqNull.Text = (val != null).ToString(); //Produced "False"
lbl_ValHasVal.Text = val.HasValue.ToString(); //Produced "False"
lbl_NValHasVal.Text = (!(val.HasValue)).ToString(); //Produced "True"
lbl_ValValEqNull.Text = (val.Value == null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")
lbl_ValValNEqNull.Text = (val.Value != null).ToString(); //Produced a runtime error. ("Nullable object must have a value.")

Lo stesso di prima. Tieni presente che l'inizializzazione con int? val = new int?(null);, con null passato al costruttore, avrebbe prodotto un errore di tempo COMPILE, poiché il valore VALUE dell'oggetto nullable NON è nullable. È solo l'oggetto wrapper stesso che può essere uguale a null.

Allo stesso modo, avremmo un errore di compilazione da:

int? val = new int?();
val.Value = null;

per non parlare del fatto che val.Valueè una proprietà di sola lettura, il che significa che non possiamo nemmeno usare qualcosa come:

val.Value = 3;

ma ancora, gli operatori di conversione implicita sovraccarica polimorfa ci permettono di fare:

val = 3;

Non c'è bisogno di preoccuparsi di polisomica, qualunque cosa accada, purché funzioni bene? :)

In VB.Net. NON utilizzare "IsNot Nothing" quando è possibile utilizzare ".HasValue". Ho appena risolto un "Operazione potrebbe destabilizzare il runtime" Errore di attendibilità medio sostituendo "IsNot Nothing" con ".HasValue" In un punto. Non capisco davvero perché, ma qualcosa sta accadendo diversamente nel compilatore. Suppongo che "! = Null" in C # potrebbe avere lo stesso problema.

Se usi linq e vuoi mantenere il codice breve, ti consiglio di usare sempre !=null

Ed è per questo che:

Immaginiamo di avere una classe Foocon una doppia variabile nullableSomeDouble

public class Foo
{
    public double? SomeDouble;
    //some other properties
}   

Se da qualche parte nel nostro codice vogliamo ottenere tutti i Foo con valori SomeDouble non nulli da una raccolta di Foo (supponendo che anche alcuni foo nella raccolta possano essere nulli), finiamo con almeno tre modi per scrivere la nostra funzione (se noi usa C # 6):

public IEnumerable<Foo> GetNonNullFoosWithSomeDoubleValues(IEnumerable<Foo> foos)
{
     return foos.Where(foo => foo?.SomeDouble != null);
     return foos.Where(foo=>foo?.SomeDouble.HasValue); // compile time error
     return foos.Where(foo=>foo?.SomeDouble.HasValue == true); 
     return foos.Where(foo=>foo != null && foo.SomeDouble.HasValue); //if we don't use C#6
}

E in questo tipo di situazione consiglio di scegliere sempre quello più corto

Risposta generale e regola empirica: se si dispone di un'opzione (ad esempio la scrittura di serializzatori personalizzati) per elaborare Nullable in pipeline diversa rispetto a object- e utilizzare le loro proprietà specifiche - farlo e utilizzare proprietà specifiche Nullable. Quindi dal punto di vista del pensiero coerente HasValuedovrebbe essere preferito. Un pensiero coerente può aiutarti a scrivere codice migliore senza spendere troppo tempo nei dettagli. Ad esempio, il secondo metodo sarà molte volte più efficace (principalmente a causa dei compilatori inline e boxe, ma i numeri fissi sono molto espressivi):

public static bool CheckObjectImpl(object o)
{
    return o != null;
}

public static bool CheckNullableImpl<T>(T? o) where T: struct
{
    return o.HasValue;
}

Test benchmark:

BenchmarkDotNet=v0.10.5, OS=Windows 10.0.14393
Processor=Intel Core i5-2500K CPU 3.30GHz (Sandy Bridge), ProcessorCount=4
Frequency=3233539 Hz, Resolution=309.2587 ns, Timer=TSC
  [Host] : Clr 4.0.30319.42000, 64bit RyuJIT-v4.6.1648.0
  Clr    : Clr 4.0.30319.42000, 64bit RyuJIT-v4.6.1648.0
  Core   : .NET Core 4.6.25009.03, 64bit RyuJIT


        Method |  Job | Runtime |       Mean |     Error |    StdDev |        Min |        Max |     Median | Rank |  Gen 0 | Allocated |
-------------- |----- |-------- |-----------:|----------:|----------:|-----------:|-----------:|-----------:|-----:|-------:|----------:|
   CheckObject |  Clr |     Clr | 80.6416 ns | 1.1983 ns | 1.0622 ns | 79.5528 ns | 83.0417 ns | 80.1797 ns |    3 | 0.0060 |      24 B |
 CheckNullable |  Clr |     Clr |  0.0029 ns | 0.0088 ns | 0.0082 ns |  0.0000 ns |  0.0315 ns |  0.0000 ns |    1 |      - |       0 B |
   CheckObject | Core |    Core | 77.2614 ns | 0.5703 ns | 0.4763 ns | 76.4205 ns | 77.9400 ns | 77.3586 ns |    2 | 0.0060 |      24 B |
 CheckNullable | Core |    Core |  0.0007 ns | 0.0021 ns | 0.0016 ns |  0.0000 ns |  0.0054 ns |  0.0000 ns |    1 |      - |       0 B |

Codice benchmark:

public class BenchmarkNullableCheck
{
    static int? x = (new Random()).Next();

    public static bool CheckObjectImpl(object o)
    {
        return o != null;
    }

    public static bool CheckNullableImpl<T>(T? o) where T: struct
    {
        return o.HasValue;
    }

    [Benchmark]
    public bool CheckObject()
    {
        return CheckObjectImpl(x);
    }

    [Benchmark]
    public bool CheckNullable()
    {
        return CheckNullableImpl(x);
    }
}

https://github.com/dotnet/BenchmarkDotNet è stato utilizzato

PS . La gente dice che i consigli "preferiscono HasValue a causa del pensiero coerente" non sono correlati e inutili. Puoi prevedere le prestazioni di questo?

public static bool CheckNullableGenericImpl<T>(T? t) where T: struct
{
    return t != null; // or t.HasValue?
}

PPS Le persone continuano a essere negative, ma nessuno prova a prevedere le prestazioni di CheckNullableGenericImpl. E lì il compilatore non ti aiuterà a sostituirlo !=nullcon HasValue. HasValuedovrebbe essere usato direttamente se sei interessato alla performance.