Review this code from a project that has just enabled nullable reference types: it is full of `!` operators, `= default!` on properties, and helper methods like TryGetCustomer that the compiler does not understand. What is wrong, and how do you make nullable annotations actually protect you? Cover the nullable attributes, generics with T?, EF Core and deserialisation.

Code under review (representative)

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; } = default!;          // silence CS8618
    public string Email { get; set; } = default!;
    public Address Address { get; set; } = default!;
    public string? Phone { get; set; }
}

public bool TryGetCustomer(int id, out Customer? customer) { ... }

if (repo.TryGetCustomer(id, out var c))
    SendEmail(c!.Email);                                   // ! because the compiler warns

var dto = JsonSerializer.Deserialize<CustomerDto>(json)!;
var city = dto.Address!.City!.ToUpper();
T? First<T>(IEnumerable<T> items) => items.FirstOrDefault();

What's wrong

The project enabled nullable reference types but then switched them off line by line:

1. = default! on properties tells the compiler "this is never null" while initialising it to null. Any new Customer() or deserialised object can have Name == null and the compiler won't warn — the exact bug NRT was meant to catch.
2. ! sprinkled at call sites (c!.Email, dto.Address!.City!) suppresses warnings without proving anything. Each ! is a potential NullReferenceException the compiler would have found.
3. Helpers the compiler doesn't understand: TryGetCustomer(out Customer? customer) returns true with a non-null customer, but without annotations the compiler assumes customer may still be null after true — so developers add !.
4. Deserialize(...)! — deserialisation can return null (for JSON null) and can leave non-nullable properties null if fields are missing; ! hides both.
5. Generic T? in First<T> doesn't mean Nullable<T> for value types: for int, T? is just int, returning 0 for "not found".
6. EF Core mapping implications: string Name (non-nullable) maps to a NOT NULL column, string? Phone to nullable — so annotations aren't cosmetic; wrong ones change the schema or hide data problems.

How to make annotations protect you

Initialise honestly. Use constructors, required members, or real defaults instead of default!:

public sealed class Customer
{
    private Customer() { }                                 // for EF Core materialisation
    public Customer(string name, EmailAddress email, Address address) { Name = name; Email = email; Address = address; }

    public int Id { get; private set; }
    public string Name { get; private set; } = null!;     // EF sets it; acceptable, documented exception
    public EmailAddress Email { get; private set; } = null!;
    public Address Address { get; private set; } = null!;
    public string? Phone { get; private set; }
}

public sealed record CustomerDto
{
    public required string Name { get; init; }
    public required string Email { get; init; }
    public AddressDto? Address { get; init; }              // honest: may be missing
}

null! remains only where a framework (EF Core) guarantees initialisation, ideally behind private setters/constructors — not on public DTOs.

Teach the compiler with attributes:

public bool TryGetCustomer(int id, [NotNullWhen(true)] out Customer? customer) { ... }
if (repo.TryGetCustomer(id, out var c)) SendEmail(c.Email);   // no ! needed

[MemberNotNull(nameof(_connection))] private void EnsureConnected() { _connection ??= Open(); }
public static string? Normalise([NotNullIfNotNull(nameof(input))] string? input) => input?.Trim();
[DoesNotReturn] static void Fail(string message) => throw new InvalidOperationException(message);

Handle deserialisation properly:

var options = new JsonSerializerOptions(JsonSerializerDefaults.Web) { RespectNullableAnnotations = true, RespectRequiredConstructorParameters = true };  // .NET 9
var dto = JsonSerializer.Deserialize<CustomerDto>(json, options) ?? throw new BadRequestException("Body required");

Plus validation (required, data annotations/FluentValidation), and mapping Address to a domain object only after checking it.

Generics: be explicit about intent:

static T? FirstOrNull<T>(IEnumerable<T> items) where T : class => items.FirstOrDefault();
static T? FirstOrNull<T>(IEnumerable<T> items, int _ = 0) where T : struct => items.Cast<T?>().FirstOrDefault();
// or a Try pattern: bool TryFirst<T>(IEnumerable<T> items, [MaybeNullWhen(false)] out T value)

Process guardrails:

• <Nullable>enable</Nullable> + <WarningsAsErrors>nullable</WarningsAsErrors>.
• Review rule: every ! needs a justification comment; prefer fixing the flow (guard clauses, ?? throw, patterns).
• Keep ArgumentNullException.ThrowIfNull at public boundaries — annotations are compile-time only.
• Review EF Core migrations after changing annotations.

A production example

After a team "enabled NRT" by adding = default! and ! everywhere, NullReferenceExceptions in Application Insights didn't drop at all. Reviewing the top NREs showed most were in exactly those suppressed places (deserialised DTOs with missing fields, Try methods). Adding [NotNullWhen(true)], required on DTOs, RespectNullableAnnotations, and removing ~300 ! operators (with real fixes) cut NREs by over 80% within two releases.