Pourquoi ne devrais-je pas toujours utiliser les types nullables en C #

Question

Je cherche de bons conseils à ce sujet depuis l’introduction du concept dans .net 2.0.

Pourquoi voudrais-je jamais utiliser des types de données non nullables en c #? (Une meilleure question est de savoir pourquoi je ne choisirais pas les types nullable par défaut et n'utiliserais que des types non-nullables lorsque cela serait explicitement utile.)

Le choix d'un type de données Nullable sur son homologue non Nullable at-il un impact important sur les performances?

Je préfère de loin comparer mes valeurs à null au lieu de Guid.empty, string.empty, DateTime.MinValue, < = 0, etc., et de travailler avec les types nullable en général. Et la seule raison pour laquelle je ne choisis pas plus souvent les types annulables est la sensation de démangeaison dans la tête qui me donne l’impression que c’est plus qu’une compatibilité ascendante qui oblige cet extra? caractère à autoriser explicitement une valeur nulle.

Y a-t-il quelqu'un qui choisit toujours (le plus souvent) des types nullables plutôt que des types non nullables?

Merci de votre temps,

Answer 1

La raison pour laquelle vous ne devriez pas toujours utiliser les types nullables est que vous pouvez parfois garantir qu'une valeur sera initialisée. Et vous devriez essayer de concevoir votre code de sorte que ce soit le cas le plus souvent possible. S'il est impossible qu'une valeur puisse être non initialisée, il n'y a aucune raison pour que null soit une valeur légale. Comme exemple très simple, considérons ceci:

List<int> list = new List<int>()
int c = list.Count;

Ceci est toujours valide. Il n’existe aucun moyen possible de désinitialiser c. Si elle était transformée en int?, vous diriez effectivement aux lecteurs du code & "; Cette valeur pourrait être nulle. Assurez-vous de vérifier avant de l'utiliser & Quot ;. Mais nous savons que cela ne peut jamais arriver, alors pourquoi ne pas exposer cette garantie dans le code?

Vous avez absolument raison dans les cas où une valeur est facultative. Si nous avons une fonction qui peut ou non renvoyer une chaîne, alors nous renvoyons null. Ne retournez pas string.Empty (). Ne retournez pas & "; Des valeurs magiques &";.

Mais toutes les valeurs ne sont pas optionnelles. Et rendre tout ce qui est optionnel rend le reste de votre code bien plus compliqué (cela ajoute un autre chemin de code à gérer).

Si vous pouvez spécifiquement garantir que cette valeur sera toujours valide, pourquoi alors jeter cette information? C'est ce que vous faites en faisant un type nullable. Maintenant, la valeur peut exister ou ne pas exister, et toute personne l'utilisant devra gérer les deux cas. Mais vous savez qu'un seul de ces cas est possible en premier lieu. Les utilisateurs de votre code ont donc une faveur et reflètent ce fait dans votre code. Tous les utilisateurs de votre code peuvent alors compter sur la validité de la valeur et ne doivent gérer qu'un seul cas au lieu de deux.

Answer 2

Parce qu'il n'est pas pratique de toujours devoir vérifier si le type nullable est null.

Évidemment, il existe des situations dans lesquelles une valeur est réellement facultative et, dans ces cas, il est logique d’utiliser un type nullable plutôt que des nombres magiques, etc., mais dans la mesure du possible, j’essaie de les éviter.

// nice and simple, this will always work
int a = myInt;

// compiler won't let you do this
int b = myNullableInt;

// compiler allows these, but causes runtime error if myNullableInt is null
int c = (int)myNullableInt;
int d = myNullableInt.Value;    

// instead you need to do something like these, cumbersome and less readable
int e = myNullableInt ?? defaultValue;
int f = myNullableInt.HasValue ? myNullableInt : GetValueFromSomewhere();

Answer 3

Je pense que les concepteurs de langage estiment que "les types de référence étant nullables par défaut" était une erreur, et que non-nullable est le seul paramètre raisonnable par défaut, et que vous devriez être obligé d'activer la nullité. (C’est le cas dans de nombreux langages fonctionnels modernes.) & Quot; null & Quot; est généralement un tas de problèmes.

Answer 4

Vous semblez avoir 2 questions différentes ...

  

Pourquoi voudrais-je jamais utiliser des types de données non nullables en C #?

Simple, car les données de type valeur sur lesquelles vous vous appuyez sont garanties par le compilateur pour avoir une valeur!

  

Pourquoi ne choisirais-je pas les types nullables par défaut et n'utiliserais-je que des types non-nullables lorsque cela fait explicitement sens?

Comme Joel l'a déjà mentionné, un type ne peut être nul s'il s'agit d'un type de référence. Les types de valeur sont garantis par le compilateur d'avoir une valeur. Si votre programme dépend d’une variable pour avoir une valeur, c’est le comportement que vous voudrez ne pas choisir un type nullable.

Bien sûr, lorsque vos données proviennent de tout ce qui ne fait pas partie de votre programme, tous les paris sont désactivés. Le meilleur exemple provient d'une base de données. Les champs de base de données peuvent être null. Par conséquent, vous voudriez que votre variable de programme imite cette valeur - et pas simplement créer un & "; Magique &"; valeur (c'est-à-dire -1, 0 ou quoi que ce soit) que & "; représente &"; <=> Vous faites cela avec des types nullables.

Answer 5

Bien que des valeurs nulles puissent être pratiques pour une utilisation en tant que & "non-initialisé-à ce jour &"; ou " non spécifié " valeurs, ils rendent le code plus complexe, principalement parce que vous surchargez la signification de null ainsi que la variable (nombre-ou-null vs juste un nombre).

De nombreux concepteurs de bases de données et programmeurs de bases de données SQL privilégient les valeurs NULL, mais avec un léger changement dans la manière de penser au problème, vous pouvez supprimer les valeurs null et obtenir un code plus simple et plus fiable (par exemple, ne vous inquiétez pas de NullReferenceException s ).

Il existe actuellement une forte demande pour un " T! " opérateur qui rend tout type de référence non nullable, similaire à la façon dont " T? " rend les types de valeur nuls, et Anders Hejlsberg, l'inventeur de C #, aurait souhaité l'inclure.

Voir aussi la question, Pourquoi & # 8220; null & # 8221; présent en C # et java?

Answer 6

J’ai tendance à utiliser les types Nullable chaque fois qu’ils ont un sens - je ne me soucierai pas de la performance tant que c’est un problème, puis je corrigerai les quelques zones où cela se trouve et nous en aurons fini.

Cependant, je constate également qu'en général, la plupart de mes valeurs finissent par être non nullables. En fait, il y a plusieurs fois où je voudrais en fait utiliser un NotNullable que je peux utiliser avec des types de référence pour identifier un problème avec null lorsque j'obtiens le null, pas plus tard lorsque j'essaie de l'utiliser.

Answer 7

La seule fois où un type Nullable devrait être utilisé, est dans le cas où un certain champ dans une table de la base de données nécessite absolument qu'un null soit envoyé ou reçu par l'application à un moment donné. Même dans un tel cas, il faut toujours essayer de trouver un moyen de contourner le type nullable. Bool n'est pas toujours votre meilleur ami.