C# 14: das field-Schlüsselwort
- Matt
Autoimplementierte Eigenschaften sind bequem, bis man eine Kleinigkeit im Setter braucht. Ein Trim(), eine Prüfung auf null, ein Standardwert. Ab da schreibt man das Feld wieder selbst:
private string _name = "";
public string Name
{
get => _name;
set => _name = value?.Trim() ?? "";
}
Drei Zeilen Gerüst für eine Zeile Logik, und ein Feld im Klassenrumpf, das niemanden außerhalb der Eigenschaft interessiert. Schlimmer noch: Es ist von überall in der Klasse erreichbar, was irgendwann jemand ausnutzt und am Setter vorbeischreibt.
C# 14 räumt damit auf. Innerhalb eines Accessors gibt es jetzt field, das auf das vom Compiler erzeugte Hintergrundfeld verweist:
public string Name
{
get;
set => field = value?.Trim() ?? "";
}
Der Getter bleibt automatisch, nur der Setter macht etwas Eigenes. Das Feld existiert weiterhin, ist aber nirgends sonst sichtbar.
Wo es sich lohnt
Am deutlichsten bei ViewModels, auch wenn das CommunityToolkit dort vieles ohnehin erzeugt, und überall sonst, wo Eigenschaften eine kleine Nebenwirkung haben:
public decimal Betrag
{
get;
set
{
if (field == value) return;
field = value;
OnPropertyChanged();
}
}
public IReadOnlyList<string> Zeilen
{
get => field ??= [];
set;
}
Das zweite Beispiel ist die verzögerte Erzeugung, die vorher zwingend ein eigenes Feld gebraucht hat. field ??= [] ist kompakt und lässt keinen Weg offen, das Feld uninitialisiert zu lesen.
Der Haken
field ist ein sogenanntes kontextabhängiges Schlüsselwort, es gilt also nur innerhalb eines Accessors. Wer dort bisher eine Variable oder ein Feld namens field hatte, bekommt eine Verhaltensänderung: Der Bezeichner meint ab C# 14 das Hintergrundfeld, nicht mehr das eigene. Der Compiler warnt davor, aber es ist die Art von Änderung, die in einer großen Codebasis unangenehm werden kann. Wer betroffen ist, kann das eigene Element umbenennen oder mit @field darauf verweisen.
Der zweite Punkt ist Gewohnheit. Die Eigenschaft sieht auf den ersten Blick aus wie eine autoimplementierte, hat aber Verhalten. Beim Überfliegen einer Klasse übersieht man das leichter als ein ausgeschriebenes Feld. Das ist kein Argument dagegen, aber ein Grund, im Setter nichts zu verstecken, was mehr tut als Zuweisen, Prüfen oder Benachrichtigen.
Insgesamt ist es eine dieser Änderungen, die man nach zwei Wochen nicht mehr bewusst wahrnimmt und dann in älterem Code vermisst.