C# 8 - Tipos de Referencia Anulables

3 de noviembre de 2019 • 4 min de lectura

Microsoft está agregando una nueva característica a C# 8 llamada Tipos de Referencia Anulables. Lo cual al principio es confuso porque todos los tipos de referencia son anulables… entonces ¿cómo es esto diferente? En adelante, si la característica está habilitada, los tipos de referencia son no anulables, a menos que los marques explícitamente como anulables.

Déjame explicarte.

Tipos de Referencia Anulables

Cuando los Tipos de Referencia Anulables están habilitados y el compilador cree que un tipo de referencia tiene el potencial de ser nulo, te advierte. Verás mensajes de advertencia de Visual Studio:

Y advertencias de compilación:

Para eliminar esta advertencia, agrega un signo de interrogación al final del tipo de referencia. Por ejemplo:

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

Ahora el tipo de referencia se comporta como lo hacía antes de C# 8.

Esta característica se habilita agregando <span class="inline-code"> #nullable enable </span> al inicio de cualquier archivo C# o agregando <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> al archivo .csproj. Por defecto no está habilitada, lo cual es bueno porque si estuviera habilitada cualquier base de código existente probablemente se iluminaría como un árbol de Navidad.

El Debate de los Nulos

¿Por qué Microsoft está agregando esta característica ahora? ¿Los nulos han sido parte del lenguaje desde, bueno, el principio? Honestamente, no sé por qué. Siempre he usado nulos, es un hecho de la vida en C#. No me di cuenta de que no tener nulos era una opción… Tal vez la vida será mejor sin ellos. Lo descubriremos.

¿Deberías o no deberías usar nulos? He resumido el debate en curso como lo entiendo.

A Favor

El argumento a favor de los nulos es generalmente que un objeto tiene un estado desconocido. Este estado desconocido se representa con null. Esto lo ves con el tipo de dato bit en SQL Server, que tiene 3 valores, null (no establecido), 0 y 1. También lo ves en las interfaces de usuario, donde a veces es importante saber si un usuario tocó un campo o no. Alguien podría contra-argumentar con, “En lugar de null, ¿por qué no crear un tipo de estado desconocido o un estado ‘no establecido’?” ¿Cómo es esto diferente de null? Aún tendrías que verificar este estado adicional. Ahora estarías creando estados desconocidos para cada instancia. ¿Por qué no simplemente usar null y tener un estado desconocido global?

En Contra

El argumento en contra de los nulos es que es un tipo de dato diferente y debe ser verificado cada vez que uses un tipo de referencia. El resultado neto es código como este:

var user = GetUser(username, password);

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

Si el método GetUser devolviera un usuario en todos los casos, incluyendo cuando el usuario no se encuentra. Si el código nunca devuelve null, entonces es un desperdicio protegerse contra ello e idealmente, esto simplifica el código. Sin embargo, en algún momento, necesitarás verificar si hay un usuario vacío y mostrar un mensaje de error. No usar null no elimina la necesidad de manejar el caso de negocio de un usuario no encontrado.

¿Es esta Característica una Buena Idea?

El propósito de esta característica NO es eliminar el uso de nulos, sino en su lugar hacer la pregunta: “¿Hay una mejor manera?” Y a veces la respuesta es “No”. Si podemos eliminar la verificación constante de nulos con un poco de previsión, lo cual a su vez simplifica nuestro código. Estoy de acuerdo. La buena noticia es que C# ha hecho que trabajar con nulos sea trivial.

Sí temo que algunos tomen una postura dogmática e insistan en eliminar los nulos en detrimento de un sistema. Esto es una tarea inútil, porque los nulos son integrales a C#.

¿Son los Tipos de Referencia Anulables una buena idea? Lo son, si el resultado final es código más simple y menos propenso a errores.