C# 8 - Nullable Referenztypen

Microsoft fügt C# 8 eine neue Funktion namens Nullable Reference Types hinzu. Dies ist zunächst verwirrend, da alle Referenztypen nullable sind… wie ist das also anders? In Zukunft sind Referenztypen, wenn die Funktion aktiviert ist, nicht nullable, es sei denn, Sie kennzeichnen sie explizit als nullable.

Lassen Sie mich das erklären.

Nullable Referenztypen

Wenn Nullable Reference Types aktiviert sind und der Compiler der Meinung ist, dass ein Referenztyp möglicherweise null ist, warnt er Sie. Sie sehen Warnmeldungen von Visual Studio:

Und Build-Warnungen:

Um diese Warnung zu entfernen, fügen Sie ein Fragezeichen am Ende des Referenztyps hinzu. Zum Beispiel:

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

Jetzt verhält sich der Referenztyp wie vor C# 8.

Diese Funktion wird aktiviert, indem Sie <span class="inline-code"> #nullable enable </span> am Anfang einer beliebigen C#-Datei hinzufügen oder <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> zur .csproj-Datei hinzufügen. Standardmäßig ist sie nicht aktiviert, was gut ist, denn wenn sie aktiviert wäre, würde wahrscheinlich jede vorhandene Codebasis wie ein Weihnachtsbaum leuchten.

Die Null-Debatte

Warum fügt Microsoft diese Funktion jetzt hinzu? Nulls sind seit Anfang an Teil der Sprache? Ehrlich gesagt weiß ich nicht warum. Ich habe immer Nulls verwendet, es ist eine Tatsache des Lebens in C#. Ich wusste nicht, dass das Fehlen von Nulls eine Option war… Vielleicht wird das Leben ohne sie besser. Wir werden es herausfinden.

Sollten Sie Nulls verwenden oder nicht? Ich habe die laufende Debatte zusammengefasst, wie ich sie verstehe.

Dafür

Das Argument für Nulls ist im Allgemeinen, dass ein Objekt einen unbekannten Zustand hat. Dieser unbekannte Zustand wird mit null dargestellt. Sie sehen dies mit dem Bit-Datentyp in SQL Server, der 3 Werte hat: null (nicht gesetzt), 0 und 1. Sie sehen dies auch in Benutzeroberflächen, wo es manchmal wichtig ist zu wissen, ob ein Benutzer ein Feld berührt hat oder nicht. Jemand könnte dagegen argumentieren: „Warum nicht statt null einen unbekannten Zustandstyp oder einen ‚nicht gesetzten’ Zustand erstellen?” Wie ist das anders als null? Sie müssten immer noch auf diesen zusätzlichen Zustand prüfen. Jetzt erstellen Sie für jede Instanz unbekannte Zustände. Warum nicht einfach null verwenden und einen globalen unbekannten Zustand haben?

Dagegen

Das Argument gegen Nulls ist, dass es ein anderer Datentyp ist und jedes Mal überprüft werden muss, wenn Sie einen Referenztyp verwenden. Das Ergebnis ist Code wie dieser:

var user = GetUser(username, password);

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

Wenn die GetUser-Methode in allen Fällen einen Benutzer zurückgeben würde, auch wenn der Benutzer nicht gefunden wird. Wenn der Code niemals null zurückgibt, ist es verschwendet, sich davor zu schützen, und idealerweise vereinfacht dies den Code. Allerdings müssen Sie irgendwann auf einen leeren Benutzer prüfen und eine Fehlermeldung anzeigen. Die Nichtverwendung von null beseitigt nicht die Notwendigkeit, den Geschäftsfall eines nicht gefundenen Benutzers zu erfüllen.

Ist diese Funktion eine gute Idee?

Der Zweck dieser Funktion ist NICHT, die Verwendung von Nulls zu eliminieren, sondern stattdessen die Frage zu stellen: „Gibt es einen besseren Weg?” Und manchmal lautet die Antwort „Nein”. Wenn wir die ständige Überprüfung auf Nulls mit etwas Voraussicht eliminieren können, was wiederum unseren Code vereinfacht, bin ich dabei. Die gute Nachricht ist, dass C# die Arbeit mit Nulls trivial gemacht hat.

Ich befürchte, dass einige eine dogmatische Haltung einnehmen und darauf bestehen, Nulls zum Nachteil eines Systems zu eliminieren. Das ist ein hoffnungsloses Unterfangen, denn Nulls sind ein integraler Bestandteil von C#.

Ist Nullable Reference Types eine gute Idee? Ja, wenn das Ergebnis einfacherer und fehlerfreier Code ist.