Laquelle est préférée: Nullable <T> .HasValue ou Nullable <T>! = Null?

J'ai toujours utilisé Nullable<>.HasValueparce que j'aimais la sémantique. Cependant, récemment, je travaillais sur la base de code existante de quelqu'un d'autre où ils l'utilisaient Nullable<> != nullexclusivement à la place.

Y a-t-il une raison de les utiliser l'un par rapport à l'autre, ou s'agit-il uniquement de préférence?

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

contre.

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

Le compilateur remplace les comparaisons nulles par un appel à HasValue, il n'y a donc pas de réelle différence. Faites simplement ce qui est plus lisible / plus logique pour vous et vos collègues.

Je préfère (a != null)que la syntaxe corresponde aux types de référence.

J'ai fait quelques recherches à ce sujet en utilisant différentes méthodes pour attribuer des valeurs à un entier nullable. Voici ce qui s'est passé lorsque j'ai fait diverses choses. Devrait clarifier ce qui se passe. Gardez à l'esprit: Nullable<something>ou le raccourci something?est une structure pour laquelle le compilateur semble faire beaucoup de travail pour nous permettre d'utiliser avec null comme s'il s'agissait d'une classe.
Comme vous le verrez ci-dessous, SomeNullable == nullet SomeNullable.HasValueretournera toujours un vrai ou un faux attendu. Bien que cela ne soit pas démontré ci-dessous, il SomeNullable == 3est également valide (en supposant que SomeNullable est un int?).
Alors que SomeNullable.Valuenous obtient une erreur d'exécution si nous avons attribué nullà SomeNullable. C'est en fait le seul cas où nullables pourrait nous poser problème, grâce à une combinaison d'opérateurs surchargés, surchargésobject.Equals(obj) méthode, et optimisation du compilateur et entreprise de singe.

Voici une description du code que j'ai exécuté et de la sortie qu'il a produite dans les étiquettes:

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, essayons la prochaine méthode d'initialisation:

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

Tout comme avant. Gardez à l'esprit que l'initialisation avec int? val = new int?(null);, avec null passé au constructeur, aurait produit une erreur de temps de compilation, car la valeur de l'objet nullable n'est PAS nullable. Seul l'objet wrapper lui-même peut être égal à null.

De même, nous obtiendrions une erreur de temps de compilation de:

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

sans compter que val.Valuec'est une propriété en lecture seule de toute façon, ce qui signifie que nous ne pouvons même pas utiliser quelque chose comme:

val.Value = 3;

mais encore une fois, les opérateurs de conversion implicites surchargés polymorphes nous permettent de faire:

val = 3;

Pas besoin de s'inquiéter de tout ce qui peut arriver, tant qu'il fonctionne bien? :)

Dans VB.Net. N'utilisez PAS "IsNot Nothing" lorsque vous pouvez utiliser ".HasValue". Je viens de résoudre une "Opération pourrait déstabiliser le runtime" Erreur de confiance moyenne en remplaçant "IsNot Nothing" par ".HasValue" à un endroit. Je ne comprends pas vraiment pourquoi, mais quelque chose se passe différemment dans le compilateur. Je suppose que "! = Null" en C # peut avoir le même problème.

Si vous utilisez linq et souhaitez garder votre code court, je recommande de toujours utiliser !=null

Et c'est pourquoi:

Imaginons que nous ayons une classe Fooavec une variable double nullableSomeDouble

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

Si, quelque part dans notre code, nous voulons obtenir tous les Foo avec des valeurs SomeDouble non nulles d'une collection de Foo (en supposant que certains foos de la collection peuvent également être nuls), nous nous retrouvons avec au moins trois façons d'écrire notre fonction (si nous utilisez 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
}

Et dans ce genre de situation, je recommande de toujours opter pour la plus courte

Réponse générale et règle générale: si vous avez une option (par exemple, écrire des sérialiseurs personnalisés) pour traiter Nullable dans un pipeline différent de object- et utiliser leurs propriétés spécifiques - faites-le et utilisez des propriétés spécifiques Nullable. Donc, d'un point de vue cohérent HasValuedevrait être préféré. Une réflexion cohérente peut vous aider à écrire un meilleur code sans passer trop de temps dans les détails. Par exemple, la deuxième méthode sera beaucoup plus efficace (principalement à cause des compilateurs en ligne et en boxe, mais les chiffres sont toujours très expressifs):

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

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

Test de référence:

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 |

Code de référence:

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 a été utilisé

PS . Les gens disent que les conseils "préfèrent HasValue en raison d'une pensée cohérente" ne sont pas liés et inutiles. Pouvez-vous prédire les performances de cela?

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

PPS Les gens continuent moins, mais personne n'essaie de prédire les performances de CheckNullableGenericImpl. Et le compilateur ne vous aidera pas à le remplacer !=nullpar HasValue. HasValuedoit être utilisé directement si vous êtes intéressé par les performances.