C# 8 - Nullable Reference Types

Microsoft legger til en ny funksjon i C# 8 kalt Nullable Reference Types. Som først er forvirrende fordi alle referansetyper er nullable… så hvordan er dette annerledes? Fremover, hvis funksjonen er aktivert, er referansetyper ikke-nullable, med mindre du eksplisitt noterer dem som nullable.

La meg forklare.

Nullable Reference Types

Når Nullable Reference Types er aktivert og kompilatoren tror en referansetype har potensial til å være null, advarer den deg. Du vil se advarselsmeldinger fra Visual Studio:

Og byggadvarsler:

For å fjerne denne advarselen, legg til et spørsmålstegn bak referansetypen. For eksempel:

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

Nå oppfører referansetypen seg som den gjorde før C# 8.

Denne funksjonen er aktivert ved å legge til <span class="inline-code"> #nullable enable </span> øverst i en hvilken som helst C#-fil eller ved å legge til <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> i .csproj-filen. Out of the box er den ikke aktivert, noe som er bra fordi hvis den var aktivert, ville enhver eksisterende kodebase sannsynligvis lyse opp som et juletre.

Null-debatten

Hvorfor legger Microsoft til denne funksjonen nå? Nulls har vært en del av språket siden, vel, begynnelsen? Ærlig talt, jeg vet ikke hvorfor. Jeg har alltid brukt nulls, det er en realitet i C#. Jeg skjønte ikke at det var et alternativ å ikke ha nulls… Kanskje livet blir bedre uten dem. Vi får se.

Bør du eller bør du ikke bruke nulls? Jeg har oppsummert den pågående debatten slik jeg forstår den.

For

Argumentet for nulls er generelt at et objekt har en ukjent tilstand. Denne ukjente tilstanden er representert med null. Du ser dette med bit-datatypen i SQL Server, som har 3 verdier, null (ikke satt), 0 og 1. Du ser også dette i brukergrensesnitt, hvor det noen ganger er viktig å vite om en bruker berørte et felt eller ikke. Noen kunne motargumentere med, “I stedet for null, hvorfor ikke lage en ukjent tilstandstype eller en ‘ikke satt’-tilstand?” Hvordan er dette annerledes enn null? Du ville fortsatt måtte sjekke for denne tilleggstilstanden. Nå lager du ukjente tilstander for hver instans. Hvorfor ikke bare bruke null og ha en global ukjent tilstand?

Mot

Argumentet mot nulls er at det er en annen datatype og må sjekkes hver gang du bruker en referansetype. Nettoresultatet er kode som dette:

var user = GetUser(username, password);

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

Hvis GetUser-metoden returnerte en bruker i alle tilfeller, inkludert når brukeren ikke blir funnet. Hvis koden aldri returnerer null, er det bortkastet å beskytte seg mot det, og ideelt sett forenkler dette koden. Men på et tidspunkt må du sjekke for en tom bruker og vise en feilmelding. Å ikke bruke null fjerner ikke behovet for å oppfylle forretningssaken om at en bruker ikke ble funnet.

Er denne funksjonen en god idé?

Formålet med denne funksjonen er IKKE å eliminere bruken av nulls, men i stedet å stille spørsmålet: “Er det en bedre måte?” Og noen ganger er svaret “Nei”. Hvis vi kan eliminere den konstante kontrollen for nulls med litt forethought, noe som igjen forenkler koden vår. Jeg er med. De gode nyhetene er at C# har gjort det trivielt å arbeide med nulls.

Jeg frykter at noen vil ta et dogmatisk standpunkt og insistere på å eliminere nulls til skade for et system. Dette er en tapt sak, fordi nulls er integrert i C#.

Er Nullable Reference Types en god idé? Det er det, hvis sluttresultatet er enklere og mindre feilbetinget kode.