C# 8 - Nullable Reference Types

Microsoft legger til en ny funksjon i C# 8 kalt Nullable Reference Types. Som ved første øyekast 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 markerer dem som nullable.

La meg forklare.

Nullable Reference Types

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

Og byggeadvarsler:

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 aktiveres 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. Den er ikke aktivert som standard, noe som er bra siden 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 vet jeg ikke hvorfor. Jeg har alltid brukt nulls, det er et faktum i C#. Jeg skjønte ikke at det å ikke ha nulls var et alternativ… Kanskje livet blir bedre uten dem. Det får vi 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 representeres 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 har berørt et felt eller ikke. Noen kan motsi med: “I stedet for null, hvorfor ikke lage en ukjent tilstandstype eller en ‘ikke satt’ tilstand?” Hvordan er dette annerledes enn null? Du måtte fortsatt 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 for 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, så 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 å fylle forretningssaken med 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 sjekking for nulls med litt forutseenhet, som igjen forenkler koden vår. Da er jeg med. De gode nyhetene er at C# har gjort det trivielt å jobbe med nulls.

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

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