Quelle est la différence entre Nullable<T>.HasValue et Nullable<T> != null ?

Question

J'ai toujours utilisé Nullable<>.HasValue parce que j'aimais la sémantique. Cependant, j'ai récemment travaillé sur la base de code existante de quelqu'un d'autre qui utilisait Nullable<> != null exclusivement.

Y a-t-il une raison d'utiliser l'un plutôt que l'autre, ou s'agit-il d'une simple préférence ?

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

vs.

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

Answer 1

Le compilateur remplace null avec un appel à HasValue Il n'y a donc pas de réelle différence. Il suffit de choisir ce qui est le plus lisible ou le plus logique pour vous et vos collègues.

Answer 2

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

Answer 3

J'ai fait quelques recherches à ce sujet en utilisant différentes méthodes pour assigner des valeurs à un int nullable. Voici ce qui s'est passé lorsque j'ai fait différentes choses. Cela devrait clarifier ce qui se passe. N'oubliez pas : Nullable<something> ou l'abréviation something? est une structure pour laquelle le compilateur semble faire beaucoup de travail pour nous permettre de l'utiliser avec null comme s'il s'agissait d'une classe.
Comme vous le verrez ci-dessous, SomeNullable == null y SomeNullable.HasValue renverra toujours un vrai ou un faux. Bien que cela ne soit pas démontré ci-dessous, SomeNullable == 3 est également valide (en supposant que SomeNullable est un int? ).
Tandis que SomeNullable.Value Nous obtenons une erreur d'exécution si nous avons assigné null a SomeNullable . C'est en fait le seul cas où les nullables pourraient nous poser problème, grâce à une combinaison d'opérateurs surchargés, de object.Equals(obj) et l'optimisation du compilateur et les affaires de singe.

Voici une description d'un code que j'ai exécuté et des résultats qu'il a produits sous forme d'é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 méthode d'initialisation suivante :

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 auparavant. 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, puisque la VALEUR de l'objet nullable n'est PAS nullable. Ce n'est que l'objet enveloppant lui-même qui peut être égal à null.

De même, nous obtiendrions une erreur au moment de la compilation à partir de :

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

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

val.Value = 3;

mais là encore, les opérateurs de conversion implicites surchargés polymorphes nous permettent de le faire :

val = 3;

Il n'y a pas lieu de s'inquiéter des polysomnies, du moment qu'elles fonctionnent bien :)

Answer 4

En VB.Net. N'utilisez PAS "IsNot Nothing" lorsque vous pouvez utiliser ".HasValue". Je viens de résoudre une erreur "Operation could destabilize the runtime" Medium trust 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.

Answer 5

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

Et voici pourquoi :

Imaginons que nous ayons une classe Foo avec un nullable double variable SomeDouble

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

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

Dans ce genre de situation, je recommande de toujours choisir le plus court.