I deleted every hand-written backing field in my codebase this week.
That sounds like a small thing, and it is. But some of the best language features are small, they don’t change what you can do, they change what you have to do. C# 14, which ships with .NET 10, is full of these. Let me show you the one that’s already changed my daily code, plus two more worth knowing.
The field keyword
Here’s the validated property I’ve written a hundred times in my career:
It works. It’s also six lines of boilerplate for what is conceptually a one-line idea: “a string property that can’t be null.” The hand-written backing field _name exists purely as plumbing, I never want to think about it, yet there it is, taking up space and naming conventions in every file.
C# 14 lets you reference the compiler-generated backing field directly with the field keyword:
That’s it. The plumbing disappears. You get validation logic with none of the field-management overhead, no _name to declare, no naming convention to remember, nothing for a reviewer to trip over.
And it’s not just cosmetics. Hand-written backing fields are a source of real bugs: someone assigns _name directly somewhere and skips the validation, or the field and property drift apart during a refactor. With field, there’s exactly one path for the value to travel. The compiler holds the plumbing, and you can’t reach around it.
I’ve been going through older code and replacing the old pattern wherever I find it. It’s the kind of cleanup that’s genuinely satisfying, each deletion is a small victory over boilerplate.
Extension members (not just methods anymore)
This one is bigger than it looks. For years, C# gave us extension methods, useful, but you couldn’t add properties, which made them feel like second-class citizens bolted onto a type from the outside.
C# 14’s extension blocks change that. You declare the receiver once, then add properties that read like native members:
Compare that with the old approach, a static helper class with methods like OrderHelpers.GetTotalWithTax(order), and the difference in readability is night and day:
Do I use this everywhere? No, and neither should you. Extension members are for genuinely cross-cutting conveniences, not for smuggling business logic into places it doesn’t belong. But for the cases where they fit, they remove a whole category of awkward helper-class indirection that I’ve always found slightly embarrassing in code reviews.
Null-conditional assignment in one line
The smallest of the three, and the one with the best effort-to-impact ratio. ?. on the left of =, null-conditional assignment:
It’s a tiny feature. But when you multiply it across a codebase, every handler, every event callback, every place where a nullable thing gets updated, the line-count impact is genuinely large. More importantly, it removes the visual noise that hides the actual intent. When I read counter?.Value += 1, I see the intent immediately. The if version makes me do a small parse of control flow for something that isn’t really a decision.
The pattern I see
C# has been quietly getting nicer for years. Not bigger, nicer. Pattern matching, records, required members, and now field, extension members, and ?. assignment. Each one removes a small friction I used to just accept as part of the job.
There’s a philosophy here worth noticing: the language team keeps finding the places where developers write the same awkward shape over and over, and they make the awkward shape unnecessary. That’s a good model for API design in general, if your users keep wrapping your code in the same helper, the helper belongs in the library.
I sometimes hear that new language features are toys for conference talks. Maybe some are. But the field keyword is already in my production code, in code I review, and in the snippet I reach for when I write a validated property without thinking. That’s the test that matters: does it survive contact with a real codebase?
What small language feature has saved you the most lines? I’m always collecting these.
