Entendendo Nullable Types no .NET

O que mudou no .NET 6 com os nullable types

Os nullable reference types chegaram ao C# 8, mas ficavam desligados por padrão. A partir do .NET 6, no entanto, todos os modelos de projeto passaram a incluir no .csproj uma configuração chamada <Nullable>, conforme o exemplo abaixo.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable> <!-- 👈 -->
  </PropertyGroup>
</Project>

Por isso, os avisos aparecem com tanta frequência em projetos novos. Segundo a referência de tipos de referência anuláveis do C#, antes do .NET 6 os projetos usavam disable como padrão.

A propriedade aceita os valores enable, disable, warnings e annotations. Também é possível ativar o recurso em um único arquivo com a diretiva #nullable enable.

Embora seja plenamente possível remover essa configuração ou atribuir o valor disable, a recomendação é mantê-la ligada. A própria Microsoft afirma que não recomenda desativar a verificação de nulos em projetos de produção.

Por que um tipo de valor não é nulo

Se você já fez nosso curso gratuito de C#, aprendeu que os tipos no .NET têm um tamanho específico. Por exemplo, um int sempre ocupa 32 bits, enquanto um short sempre ocupa 16 bits.

Essa tipagem ajuda muito na alocação de memória. Afinal, todo programa vai para a memória antes de ser executado, e saber que uma estrutura precisa de X bytes facilita a organização dos dados.

Dessa forma, não faz sentido inicializar um tipo de valor com nulo. Qual seria a vantagem de pedir 4 bytes ao computador e não colocar nenhum valor lá?

Tipos de referência são os vilões

Sabemos, então, que os tipos de valor armazenam a própria informação. Mas e os tipos de referência, o que são eles?

Diferente dos tipos de valor, os tipos de referência armazenam apenas um endereço, ou seja, uma referência para o lugar da memória onde os dados estão. Esse comportamento traz mais dinamismo, porque permite trabalhar com estruturas de tamanho variável.

Um ótimo exemplo de tipo de referência é a string, que representa uma sequência de caracteres (char). Como podemos ter textos de qualquer tamanho, faz todo sentido tratá-los como referência.

Então, quando temos uma string, temos na verdade uma referência para o conjunto de caracteres que está em algum lugar da memória. Claro que existe muito mais por baixo dessa explicação, como literais internadas e imutabilidade, mas você pegou a ideia.

Resumindo, ao declarar uma string, dizemos algo como "olha, as informações desta string estão naquele endereço". Se esse endereço não aponta para lugar nenhum, a referência é nula.

Para entender como o runtime gerencia essas áreas da memória, vale ler também o artigo sobre o Garbage Collector no C#.

E qual o problema de ter uma referência nula

O maior problema de uma referência nula aparece quando tentamos acessar o seu valor. Sempre que fazemos isso no .NET, recebemos uma exceção do tipo NullReferenceException.

Um caso clássico acontece quando trabalhamos com listas e esquecemos de inicializá-las:

public class Order
{
    public List<Product> Products { get; set; }
    // ⚠️ Lista não inicializada, vai dar erro
}

var order = new Order();
order.Products.Add(product);
// ❌ NullReferenceException: Products é null

Isso vale para todo tipo de referência. Como consequência, sem ajuda do compilador, precisaríamos verificar se o objeto aponta para nulo antes de qualquer acesso.

💡 APRENDA C# DE GRAÇA com o curso Fundamentos do C#. São 144 aulas divididas em 14 módulos com mais de 12 horas de duração, totalmente gratuito e com certificado de conclusão.

Inicializando as propriedades

Como Name é do tipo string, precisamos inicializá-lo, e para tipos simples isso é relativamente fácil.

public class Student
{
    public string Name { get; set; } = string.Empty;
    // ✅ OK
}

public class StudentWithDefaultName
{
    public string Name { get; set; } = "André";
    // ✅ OK
}

Também podemos inicializar a propriedade pelo construtor. Nesse caso, o compilador entende que a propriedade não recebe valor de imediato, mas recebe assim que o objeto é construído.

public class Student
{
    public Student()
    {
        Name = string.Empty;
        // ✅ OK
    }

    public string Name { get; set; } // ✅ OK
}

É importante salientar que, se houver vários construtores, você precisa inicializar a propriedade em todos eles. Por isso, talvez seja mais simples usar o primeiro exemplo desta seção.

public class Student
{
    protected Student()
    {
        // ⚠️ Continuará com o warning, pois Name não foi inicializado aqui
    }

    public Student(string name)
    {
        Name = name;
        // ✅ OK
    }

    public string Name { get; set; } // ⚠️
}

Membros required

A partir do C# 11, disponível no .NET 7 e no .NET 8, existe uma alternativa elegante: o modificador required. Com ele, quem cria o objeto fica obrigado a informar o valor da propriedade.

public class Customer
{
    public required string Name { get; set; }
}

var customer = new Customer { Name = "André" }; // ✅ OK
// var invalid = new Customer();               // ❌ erro de compilação

Dessa forma, o aviso CS8618 desaparece e o compilador garante que Name sempre terá um valor. A documentação do EF Core sobre nullable reference types chega a apontar os membros required como solução ideal para entidades.

Nullable value types e a estrutura Nullable

Para tipos de valor, o ? é um syntax sugar (um apelido) para a estrutura Nullable<T>. Assim, tanto faz escrever Nullable<DateTime> ou DateTime?.

public Nullable<DateTime> CreatedAt { get; set; }
public DateTime? UpdatedAt { get; set; }

Um bool?, por exemplo, aceita true, false ou null. A estrutura oferece as propriedades HasValue e Value, além do método GetValueOrDefault().

int? score = null;
Console.WriteLine(score.HasValue);          // False

int finalScore = score ?? -1;               // -1
int safeScore = score.GetValueOrDefault();  // 0

Cuidado ao ler Value sem verificar antes. Quando HasValue é false, essa propriedade lança um InvalidOperationException, como mostra a referência de nullable value types.

Nullable reference types com o operador ?

Para tipos de referência, o ? não cria um Nullable<T>. Na verdade, ele é apenas uma anotação que informa ao compilador a sua intenção, tanto que Nullable<string> nem compila.

Em resumo, sempre que você quiser deixar explícito que um tipo pode receber nulo, use o ? depois do tipo.

public class Student
{
    public Name? Name { get; set; }
    public DateTime? UpdatedAt { get; set; }
}

public class Name
{
    public string? FirstName { get; set; }
    public string? LastName { get; set; }
}

Dessa forma, o compilador não exibe mais o aviso de inicialização, já que você mesmo declarou que aceita nulos nessas propriedades. Em troca, ele passa a avisar sempre que você tentar acessar Name.FirstName sem antes verificar se Name é nulo.

if (student.Name is not null)
{
    Console.WriteLine(student.Name.FirstName);
}

// ou, de forma mais curta
Console.WriteLine(student.Name?.FirstName ?? "No name");

No EF Core, essa anotação também tem efeito no banco. Com os nullable types ativados, uma propriedade string? vira coluna opcional e uma string vira coluna obrigatória.

Null NOT não é NOT NULL

É importante frisar que o null NOT não tem relação com o NOT NULL. O NOT NULL é uma comparação, com implementação e finalidade totalmente diferentes.

if (name is not null)
{
    // name tem valor aqui
}

if (name != null)
{
    // name tem valor aqui
}

Enquanto o null! só silencia o compilador, essas comparações verificam o valor em tempo de execução. Além disso, depois de um is not null, a análise de estado nulo já entende que a variável é segura dentro do bloco.