Was wird bevorzugt: Nullable <T> .HasValue oder Nullable <T>! = Null?

Ich habe es immer benutzt, Nullable<>.HasValueweil mir die Semantik gefallen hat. Vor kurzem habe ich jedoch an der vorhandenen Codebasis einer anderen Person gearbeitet, die Nullable<> != nullstattdessen ausschließlich verwendet wurde.

Gibt es einen Grund, einen über den anderen zu verwenden, oder ist es eine reine Präferenz?

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

vs.

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

Der Compiler ersetzt Nullvergleiche durch einen Aufruf von HasValue, sodass es keinen wirklichen Unterschied gibt. Tun Sie einfach, was für Sie und Ihre Kollegen lesbarer / sinnvoller ist.

Ich bevorzuge (a != null)es, dass die Syntax mit Referenztypen übereinstimmt.

Ich habe einige Nachforschungen angestellt, indem ich verschiedene Methoden verwendet habe, um einem nullbaren int Werte zuzuweisen. Folgendes ist passiert, als ich verschiedene Dinge getan habe. Sollte klären, was los ist. Denken Sie daran: Nullable<something>oder die Kurzschrift something?ist eine Struktur, für die der Compiler anscheinend viel Arbeit leistet, damit wir sie mit null verwenden können, als wäre es eine Klasse.
Wie Sie unten sehen werden, SomeNullable == nullund SomeNullable.HasValuewird immer wieder zurückkehren ein wahr oder falsch erwartet. Obwohl unten nicht gezeigt, SomeNullable == 3ist es auch gültig (vorausgesetzt, SomeNullable ist ein int?).
Während SomeNullable.Valueuns einen Laufzeitfehler bekommt , wenn wir zugewiesen nullzu SomeNullable. Dies ist in der Tat der einzige Fall, in dem Nullables dank einer Kombination überladener Operatoren, die überladen sind, ein Problem verursachen könnenobject.Equals(obj) Methode und Compiler-Optimierung und Affengeschäft.

Hier ist eine Beschreibung von Code, den ich ausgeführt habe, und welche Ausgabe er in Labels erzeugt hat:

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, versuchen wir die nächste Initialisierungsmethode:

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

Trotzdem wie zuvor. int? val = new int?(null);Beachten Sie, dass das Initialisieren mit , wobei null an den Konstruktor übergeben wurde, einen COMPILE-Zeitfehler erzeugt hätte, da der Wert des nullbaren Objekts NICHT nullwertfähig ist. Nur das Wrapper-Objekt selbst kann gleich null sein.

Ebenso würden wir einen Kompilierungszeitfehler erhalten von:

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

ganz zu schweigen davon, dass dies val.Valuesowieso eine schreibgeschützte Eigenschaft ist, was bedeutet, dass wir nicht einmal so etwas verwenden können wie:

val.Value = 3;

Aber auch hier können wir mit polymorphen überladenen impliziten Konvertierungsoperatoren Folgendes tun:

val = 3;

Sie müssen sich keine Sorgen um Polysomthing machen, was auch immer funktioniert, solange es richtig funktioniert? :) :)

In VB.Net. Verwenden Sie NICHT "IsNot Nothing", wenn Sie ".HasValue" verwenden können. Ich habe gerade einen mittleren Vertrauensfehler "Operation könnte die Laufzeit destabilisieren" gelöst, indem ich "IsNot Nothing" an einer Stelle durch ".HasValue" ersetzt habe. Ich verstehe nicht wirklich warum, aber im Compiler passiert etwas anders. Ich würde annehmen, dass "! = Null" in C # das gleiche Problem haben könnte.

Wenn Sie linq verwenden und Ihren Code kurz halten möchten, empfehle ich, immer zu verwenden !=null

Und deshalb:

Lassen Sie sich vorstellen , wir eine Klasse Foomit einer Nullable - Doppel VariableSomeDouble

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

Wenn wir irgendwo in unserem Code alle Foo mit einem SomeDouble-Wert ungleich Null aus einer Sammlung von Foo erhalten möchten (vorausgesetzt, einige Foos in der Sammlung können auch null sein), haben wir am Ende mindestens drei Möglichkeiten, unsere Funktion zu schreiben (wenn wir benutze 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
}

Und in solchen Situationen empfehle ich, immer die kürzere zu wählen

Allgemeine Antwort und Faustregel: Wenn Sie die Möglichkeit haben (z. B. benutzerdefinierte Serializer zu schreiben), Nullable in einer anderen Pipeline zu verarbeiten als object- und ihre spezifischen Eigenschaften zu verwenden -, tun Sie dies und verwenden Sie Nullable-spezifische Eigenschaften. Aus konsequenter Sicht HasValuesollte daher bevorzugt werden. Konsequentes Denken kann Ihnen helfen, besseren Code zu schreiben, ohne zu viel Zeit mit Details zu verbringen. Zum Beispiel wird die zweite Methode um ein Vielfaches effektiver sein (hauptsächlich aufgrund von Inlinern und Boxen von Compilern, aber dennoch sind Zahlen sehr aussagekräftig):

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

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

Benchmark-Test:

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 |

Benchmark-Code:

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 wurde verwendet

PS . Die Leute sagen, dass Ratschläge "HasValue wegen konsequentem Denken bevorzugen" nicht verwandt und nutzlos sind. Können Sie die Leistung davon vorhersagen?

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

PPS- Leute fahren mit Minus fort, aber niemand versucht, die Leistung von vorherzusagen CheckNullableGenericImpl. Und dort hilft Ihnen der Compiler nicht beim Ersetzen !=nulldurch HasValue. HasValuesollte direkt verwendet werden, wenn Sie an Leistung interessiert sind.