C# 8 - Nullable Reference Types

Microsoft fügt C# 8 eine neue Funktion namens Nullable Reference Types hinzu. Was zunächst verwirrend ist, da alle Referenztypen nullable sind… wie unterscheidet sich das also? Zukünftig 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 Reference Types

Wenn Nullable Reference Types aktiviert sind und der Compiler glaubt, dass ein Referenztyp das Potenzial hat, null zu sein, warnt er Sie. Sie werden Warnmeldungen von Visual Studio sehen:

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 jede bestehende Codebasis wahrscheinlich wie ein Weihnachtsbaum aufleuchten.

Die Null-Debatte

Warum fügt Microsoft diese Funktion jetzt hinzu? Nulls sind seit, nun ja, dem Anfang Teil der Sprache? Ehrlich gesagt weiß ich nicht warum. Ich habe immer Nulls verwendet, es ist eine Tatsache des Lebens in C#. Mir war nicht bewusst, dass keine Nulls zu haben eine Option war… Vielleicht wird das Leben ohne sie besser sein. 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 das beim bit-Datentyp in SQL Server, der 3 Werte hat: null (nicht gesetzt), 0 und 1. Sie sehen das auch in Benutzeroberflächen, wo es manchmal wichtig ist zu wissen, ob ein Benutzer ein Feld berührt hat oder nicht. Jemand könnte entgegnen: “Anstatt null, warum nicht einen unbekannten Zustandstyp oder einen ‘nicht gesetzt’-Zustand erstellen?” Wie unterscheidet sich das von null? Sie müssten trotzdem auf diesen zusätzlichen Zustand prüfen. Jetzt erstellen Sie unbekannte Zustände für jede Instanz. 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 Nettoergebnis 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, dann ist es Verschwendung, sich dagegen zu schützen, und idealerweise vereinfacht dies den Code. Jedoch müssen Sie irgendwann auf einen leeren Benutzer prüfen und eine Fehlermeldung anzeigen. Null nicht zu verwenden beseitigt nicht die Notwendigkeit, den Geschäftsfall eines nicht gefundenen Benutzers zu behandeln.

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 auf der Eliminierung von Nulls zum Nachteil eines Systems bestehen werden. Das ist ein aussichtsloses Unterfangen, weil Nulls integraler Bestandteil von C# sind.

Sind Nullable Reference Types eine gute Idee? Das sind sie, wenn das Endergebnis einfacherer und weniger fehleranfälliger Code ist.