C# 8 - Types de référence nullable

Microsoft ajoute une nouvelle fonctionnalité à C# 8 appelée Types de référence nullable. Au premier abord, c’est confus car tous les types de référence sont nullables… alors comment c’est différent ? À partir de maintenant, si la fonctionnalité est activée, les types de référence sont non-nullables, sauf si vous les notez explicitement comme nullables.

Laissez-moi expliquer.

Types de référence nullable

Lorsque les types de référence nullable sont activés et que le compilateur pense qu’un type de référence risque d’être null, il vous avertit. Vous verrez des messages d’avertissement de Visual Studio :

Et les avertissements de compilation :

Pour supprimer cet avertissement, ajoutez un point d’interrogation après le type de référence. Par exemple :

public string StringTest()
{
    string? notNull = null;
    return notNull;
}

Maintenant, le type de référence se comporte comme il l’était avant C# 8.

Cette fonctionnalité est activée en ajoutant <span class="inline-code"> #nullable enable </span> en haut de n’importe quel fichier C# ou en ajoutant <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> au fichier .csproj. Par défaut, elle n’est pas activée, ce qui est une bonne chose car si elle était activée, n’importe quelle base de code existante s’illuminerait probablement comme un sapin de Noël.

Le débat sur les valeurs null

Pourquoi Microsoft ajoute-t-elle cette fonctionnalité maintenant ? Les valeurs null font partie du langage depuis, eh bien, le début ? Honnêtement, je ne sais pas pourquoi. J’ai toujours utilisé les valeurs null, c’est un fait de la vie en C#. Je ne réalisais pas que ne pas avoir de valeurs null était une option… Peut-être que la vie sera meilleure sans elles. Nous verrons.

Devriez-vous ou ne devriez-vous pas utiliser les valeurs null ? J’ai résumé le débat en cours tel que je le comprends.

Pour

L’argument en faveur des valeurs null est généralement qu’un objet a un état inconnu. Cet état inconnu est représenté par null. Vous voyez cela avec le type de données bit dans SQL Server, qui a 3 valeurs, null (non défini), 0 et 1. Vous voyez également cela dans les interfaces utilisateur, où il est parfois important de savoir si un utilisateur a touché un champ ou non. Quelqu’un pourrait contre-argumenter en disant : « Au lieu de null, pourquoi ne pas créer un type d’état inconnu ou un état ‘non défini’ ? » En quoi c’est différent de null ? Vous devriez toujours vérifier cet état supplémentaire. Maintenant, vous créez des états inconnus pour chaque instance. Pourquoi ne pas simplement utiliser null et avoir un état inconnu global ?

Contre

L’argument contre les valeurs null est que c’est un type de données différent et doit être vérifié à chaque fois que vous utilisez un type de référence. Le résultat net est un code comme celui-ci :

var user = GetUser(username, password);

if(user != null)
{
    DoSomethingWithUser(user);
} else 
{
    SetUserNotFoundErrorMessage()
}

Si la méthode GetUser retournait un utilisateur dans tous les cas, y compris lorsque l’utilisateur n’est pas trouvé. Si le code ne retourne jamais null, alors c’est une perte de se protéger contre cela et idéalement, cela simplifie le code. Cependant, à un moment donné, vous devrez vérifier un utilisateur vide et afficher un message d’erreur. Ne pas utiliser null n’élimine pas le besoin de remplir le cas métier d’un utilisateur non trouvé.

Cette fonctionnalité est-elle une bonne idée ?

Le but de cette fonctionnalité n’est PAS d’éliminer l’utilisation des valeurs null, mais plutôt de poser la question : « Y a-t-il une meilleure façon ? » Et parfois la réponse est « Non ». Si nous pouvons éliminer la vérification constante des valeurs null avec un peu de réflexion préalable, ce qui simplifie à son tour notre code. Je suis partant. La bonne nouvelle est que C# a rendu le travail avec les valeurs null trivial.

Je crains que certains ne prennent une position dogmatique et n’insistent sur l’élimination des valeurs null au détriment d’un système. C’est une quête insensée, car les valeurs null sont intégrales à C#.

Les types de référence nullable sont-ils une bonne idée ? Oui, si le résultat final est un code plus simple et moins sujet aux erreurs.