C# 8 - Types de Référence Nullable

Microsoft ajoute une nouvelle fonctionnalité à C# 8 appelée Types de Référence Nullable. Ce qui, au premier abord, est déroutant car tous les types de référence sont nullable… alors en quoi est-ce différent ? Dorénavant, si la fonctionnalité est activée, les types de référence sont non-nullable, sauf si vous les annotez explicitement comme nullable.

Laissez-moi vous expliquer.

Types de Référence Nullable

Lorsque les Types de Référence Nullable sont activés et que le compilateur estime qu’un type de référence a le potentiel d’être null, il vous avertit. Vous verrez des messages d’avertissement de Visual Studio :

Et des avertissements de compilation :

Pour supprimer cet avertissement, ajoutez un point d’interrogation à la fin du 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 le faisait 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, toute base de code existante s’illuminerait probablement comme un sapin de Noël.

Le Débat sur Null

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

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

Pour

L’argument en faveur des nulls 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 aussi cela dans les interfaces utilisateur, où parfois il est important de savoir si un utilisateur a touché un champ ou non. Quelqu’un pourrait rétorquer : “Au lieu de null, pourquoi ne pas créer un type d’état inconnu ou un état ‘non défini’ ?” En quoi est-ce différent de null ? Vous devriez quand même 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 nulls 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 du code comme ceci :

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 quand l’utilisateur n’est pas trouvé. Si le code ne retourne jamais null, alors c’est un gaspillage de s’en protéger 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 ne supprime pas le besoin de gérer 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 nulls, 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 nulls avec un peu de réflexion préalable, ce qui simplifie notre code en retour. Je suis partant. La bonne nouvelle est que C# a rendu le travail avec les nulls trivial.

Je crains que certains adoptent une position dogmatique et insistent pour éliminer les nulls au détriment d’un système. C’est une mission impossible, car les nulls sont intégraux à C#.

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