Das neue Feldschlüsselwort in C# 14

Das Setup: Ein einfaches Personmodell

[0:12 - 1:07] Tim beginnt mit einer Konsolenanwendung, die auf .NET 10 und Visual Studio 2026 läuft. Die Demo zentriert sich auf eine Person-Klasse mit einigen Eigenschaften:

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

Es gibt auch eine durch ein privates Feld unterstützte Demo-Eigenschaft, die relevant wird, sobald der Namenskonflikt auftaucht. In Program.cs erstellt Tim eine Instanz mit FirstName = "Tim" und LastName = "Corey" und druckt dann den Nachnamen, das Alter und den Demo-Wert. Alles gibt wie erwartet aus: "Corey", 0 (der Standard-Ganzzahlwert) und "test".

Das Problem: Autopropetys akzeptieren fehlerhafte Daten

[1:23 - 2:49] Die Probleme tauchen auf, wenn Tim null zu LastName nach der Konstruktion zuweist:

p.LastName = null;

p.LastName = null;

Obwohl LastName als required markiert und als nicht-nullbarer String getippt ist, kompiliert die Zuweisung. Der required-Modifikator erzwingt nur, dass während der Objektinitialisierung ein Wert bereitgestellt wird; es verhindert nicht, dass jemand die Eigenschaft anschließend auf null setzt. Das Ergebnis ist ein leerer Nachname zur Laufzeit, ohne dass ein Fehler ausgelöst wird.

Das ist eine reale Lücke in der Datenintegrität. Das Typsystem warnt Sie mit einem nullable Reference Squiggle, aber das ist ein Kompilierungszeit-Hinweis, kein Laufzeitwächter. Wenn Ihre Anwendung darauf angewiesen ist, dass LastName immer einen gültigen String enthält, können Auto-Eigenschaften allein diesen Vertrag nicht durchsetzen.

Die alte Lösung: Vollständige Eigenschaften mit manuellen Hintergrundfeldern

[2:58 - 4:19] Vor C# 14 war die Standardlösung, die Autopropety in eine vollständige Eigenschaft mit einem expliziten Hintergrundfeld zu konvertieren:

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

Tim führt dies aus und bestätigt, dass die Ausnahme korrekt ausgelöst wird: "Wert darf nicht null sein. Parametername: LastName." Der Ansatz funktioniert, erfordert jedoch die Deklaration eines privaten Felds, das Verkabeln von Getter und Setter und das Wiederholen des Eigenschaftsnnamens über mehrere Zeilen. Für eine einzelne Validierungsregel ist das viel Zeremonie.

Der Getter in diesem Fall tut nichts Besonderes; er gibt das Feld unverändert zurück. Dennoch müssen Sie ihn explizit schreiben, da die Syntax beide Hälften erfordert, sobald Sie den Autopropety-Bereich verlassen. Tim rahmt diese Geschwätzigkeit als Motivation für das neue Feature.

Die C# 14 Lösung: Das field Schlüsselwort

[4:23 - 5:47] C# 14 führt einen Mittelweg ein. Anstatt ein privates Hintergrundfeld selbst zu deklarieren, verwenden Sie das kontextabhängige Schlüsselwort field innerhalb eines Getters oder Setters, um direkt auf das vom Compiler generierte Hintergrundfeld zu verweisen:

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

Der Getter bleibt eine automatisch implementierte get; ohne erforderlichen Körper. Der Setter verwendet field, um den kommenden value nach der Validierung zuzuweisen. Der Compiler erstellt und verwaltet das Hintergrundfeld im Hintergrund, genau wie bei einem Standard-Autopropety.

Der Demo-Lauf erzeugt dasselbe ArgumentNullException bei der Null-Zuweisung. Das Verhalten ist identisch mit der manuell unterstützten Version, komprimiert von sieben Zeilen zu einem fokussierten Block, der nur anpasst, was angepasst werden muss. Sie behalten den Autopropety-Getter, fügen Logik nur zum Setter hinzu und überspringen die manuelle Felderklärung vollständig.

Dies bietet eine nützliche Zwischenstufe zwischen einer einfachen Autopropety (eine Zeile, keine Validierung) und einer vollständigen Eigenschaft (sieben oder mehr Zeilen, vollständige Kontrolle). Wenn Ihre Logik nur den Setter betrifft, zahlen Sie nicht mehr den syntaktischen Preis, den Getter auch umzuschreiben.

Alter mit einer Setter-Wache validieren

[6:16 - 7:39] Um zu zeigen, dass field nicht auf Nullüberprüfungen beschränkt ist, fügt Tim eine Bereichsvalidierung zu der Age Eigenschaft hinzu:

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

Hier ignoriert der Setter leise Werte außerhalb eines vernünftigen Bereichs. Das Zuweisen von -5 lässt Age bei seinem Standardwert von Null, weil die Bedingung fehlschlägt und field nie geschrieben wird. Tim bemerkt, dass Sie stattdessen eine Ausnahme werfen könnten, aber der stille Ansatz zeigt, dass der Setter-Körper jede Logik enthalten kann, die Sie benötigen, während er immer noch auf field für die Speicherung angewiesen ist.

Das Muster gilt allgemein: Einengung numerischer Bereiche, Entfernen von Leerzeichen aus Zeichenketten, Normalisierung von Groß-/Kleinschreibung oder jede Transformation, die Sie jedes Mal anwenden möchten, wenn eine Eigenschaft gesetzt wird.

Namenskonflikte mit vorhandenen field Variablen

[7:39 - 9:43] Tim stellt einen absichtlichen Grenzfall vor. Die Demo-Klasse hat ein privates Mitglied, das buchstäblich field heißt:

private string field = "test";

private string field = "test";

Sobald C# 14 aktiv ist, behandelt der Compiler field innerhalb eines Eigenschafts-Accessors als Schlüsselwort statt als Variable. Das bedeutet, dass eine Eigenschaft, die auf field verweist, stillschweigend aus dem versteckten Speicher hinter der Eigenschaft liest (der leer ist) anstatt vom String-Mitglied, das "test" enthält. Die Ausgabe ändert sich in leer, ohne Kompilierfehler, nur eine Warnung.

Es gibt zwei Workarounds. Das Präfixen mit this.field sagt dem Compiler, dass Sie das Klassenebenenmitglied meinen und nicht das Schlüsselwort. Alternativ funktioniert das @field-Escape auf dieselbe Weise:

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

Tims starke Empfehlung ist, alle Variablen, die field genannt werden, umzubenennen, wenn Sie auf C# 14 upgraden. Ein schnelles "Alle umbenennen" in Ihrer IDE beseitigt die Mehrdeutigkeit dauerhaft. Der Konflikt tritt nur innerhalb von Eigenschaftenzugriffen auf; Konstruktoren und Methoden lösen field wie erwartet auf den Variablennamen auf, da diese Kontexte keinen impliziten Hintergrundspeicher haben.

Zusammenfassung: Weniger Boilerplate, gleiche Kontrolle

[10:04 - 10:28] Das field-Schlüsselwort füllt eine praktische Lücke im alltäglichen C#-Code. Eigenschaften, die eine Schutzklausel oder Transformation benötigen, erfordern nicht mehr eine komplette Umschreibung mit manuellen Sicherungsfeldern. Sie passen nur den Accessor an, der Logik benötigt und lassen den anderen als Standard-Autoumsetzung.

Abschluss

[10:28 - 10:35] Zusammengefasst: C# 14's field-Schlüsselwort gibt Ihnen direkten Zugriff auf den impliziten Hintergrundspeicher innerhalb jedes Eigenschafts-Accessors. Verwenden Sie es, um Setter-Validierungen, Getter-Transformationen oder beides hinzuzufügen, ohne die Autoproperty-Syntax für Teile aufzugeben, die keine Anpassung benötigen.

Bevor Sie upgraden, durchsuchen Sie Ihren Code für alle Variablen, die field genannt werden, und benennen Sie sie um. Diese eine Vorsichtsmaßnahme vermeidet das einzige wirkliche Problem, das diese Funktion einführt. Darüber hinaus ist es eine klare Reduzierung von Boilerplate, die sich natürlich in die Strukturierung der Modelle der meisten Entwickler integriert.

Beispieltipp: Wenn Sie nur den Setter validieren müssen, lassen Sie den Getter als einfachen get; ohne Körper. Der Compiler behandelt es als Autoproperty-Getter, und Sie vermeiden es, eine Durchlaufrückgabe-Anweisung zu schreiben, die nichts hinzufügt.

Sehen Sie das vollständige Video auf seinem YouTube Kanal und gewinnen Sie weitere Einblicke in C#-Sprachfunktionen.