Który jest preferowany: Nullable <T> .HasValue lub Nullable <T>! = Null?

Zawsze używałem, Nullable<>.HasValueponieważ lubiłem semantykę. Jednak ostatnio pracowałem nad czyjąś bazą kodów, w której używały one Nullable<> != nullwyłącznie zamiast tego.

Czy istnieje powód, aby używać jednego nad drugim, czy to czysta preferencja?

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

vs.

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

Kompilator zastępuje porównania zerowe wywołaniem do HasValue, więc nie ma prawdziwej różnicy. Po prostu rób to, co jest bardziej czytelne / ma sens dla ciebie i twoich kolegów.

Wolę, (a != null)aby składnia pasowała do typów referencji.

Zrobiłem trochę badań na ten temat, używając różnych metod, aby przypisać wartości do wartości zerowej int. Oto, co się stało, gdy zrobiłem różne rzeczy. Powinien wyjaśnić, co się dzieje. Pamiętaj: Nullable<something>albo stenografia something?jest strukturą, dla której kompilator wydaje się wykonywać wiele pracy, abyśmy mogli używać wartości zerowej, jakby to była klasa.
Jak zobaczycie poniżej, SomeNullable == nulli SomeNullable.HasValuezawsze zwraca oczekiwane prawdziwe lub fałszywe. Chociaż nie pokazano poniżej, SomeNullable == 3jest również poprawny (zakładając, że SomeNullable jest an int?).
Podczas gdy SomeNullable.Valuedostaje nam błąd czasu wykonania, jeśli przypisaliśmy nulldo SomeNullable. Jest to w rzeczywistości jedyny przypadek, w którym wartości zerowe mogą sprawić nam problem, dzięki kombinacji przeciążonych operatorów, przeciążonychobject.Equals(obj) metoda oraz optymalizacja kompilatora i małpia firma.

Oto opis jakiegoś kodu, który uruchomiłem, i jaki wynik wygenerował w etykietach:

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, spróbujmy następnej metody inicjalizacji:

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.")

Wszystko tak samo jak poprzednio. Należy pamiętać, że inicjowanie za pomocą int? val = new int?(null);, z pustym przekazanym do konstruktora, spowodowałoby błąd czasowy KOMPILACJA, ponieważ WARTOŚĆ obiektu zerowalnego NIE jest dopuszczalna. Tylko sam obiekt otoki może mieć wartość null.

Podobnie otrzymalibyśmy błąd czasu kompilacji z:

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

nie wspominając, że i tak val.Valuejest to właściwość tylko do odczytu, co oznacza, że ​​nie możemy nawet użyć czegoś takiego:

val.Value = 3;

ale znowu polimorficzne przeciążone niejawne operatory konwersji pozwalają nam na:

val = 3;

Nie musisz się jednak martwić o wieloskładnikowe, o ile działa dobrze? :)

W VB.Net. NIE używaj „IsNot Nothing”, gdy możesz użyć „.HasValue”. Właśnie rozwiązałem problem „Operacja może zdestabilizować środowisko uruchomieniowe” Średni błąd zaufania, zastępując „IsNot Nothing” słowem „.HasValue” w jednym miejscu. Naprawdę nie rozumiem dlaczego, ale w kompilatorze dzieje się inaczej. Zakładam, że „! = Null” w języku C # może mieć ten sam problem.

Jeśli używasz linq i chcesz skrócić swój kod, polecam zawsze używać !=null

I dlatego:

Wyobraźmy sobie, że mamy klasę Fooz podwójną zmienną nullSomeDouble

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

Jeśli gdzieś w naszym kodzie chcemy uzyskać wszystkie Foo z wartością zerową SomeDouble z kolekcji Foo (zakładając, że niektóre foos w kolekcji również mogą mieć wartość null), otrzymamy co najmniej trzy sposoby na napisanie naszej funkcji (jeśli użyj 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
}

I w takiej sytuacji polecam zawsze wybierać krótszą

Ogólna odpowiedź i ogólna zasada: jeśli masz opcję (np. Pisanie niestandardowych serializatorów), aby przetworzyć wartość Nullable w innym potoku niż object- i użyć ich określonych właściwości - zrób to i użyj właściwości Nullable. Dlatego z punktu widzenia konsekwentnego myślenia HasValuenależy preferować. Konsekwentne myślenie może pomóc Ci napisać lepszy kod, nie poświęcając zbyt wiele czasu na szczegóły. Np. Druga metoda będzie wielokrotnie skuteczniejsza (głównie ze względu na wstawianie i boksowanie kompilatorów, ale wciąż liczby są bardzo wyraziste):

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

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

Test porównawczy:

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 |

Kod testu porównawczego:

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);
    }
}

Wykorzystano https://github.com/dotnet/BenchmarkDotNet

PS . Ludzie mówią, że rada „wolę HasValue ze względu na konsekwentne myślenie” nie jest powiązana i bezużyteczna. Czy potrafisz przewidzieć wydajność tego?

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

Ludzie PPS kontynuują minus, ale nikt nie próbuje przewidzieć wydajności CheckNullableGenericImpl. I tam kompilator nie pomoże wymianie !=nullz HasValue. HasValuenależy stosować bezpośrednio, jeśli jesteś zainteresowany wydajnością.