{"id":8707,"date":"2025-03-13T11:44:00","date_gmt":"2025-03-13T10:44:00","guid":{"rendered":"https:\/\/www.fores.group\/?p=8707"},"modified":"2025-09-14T14:13:24","modified_gmt":"2025-09-14T12:13:24","slug":"efficient-collection-management-in-c-optimize-your-code-performance","status":"publish","type":"post","link":"https:\/\/www.fores.group\/sk\/efficient-collection-management-in-c-optimize-your-code-performance\/","title":{"rendered":"My favorite C# features in<\/span> real world use cases<\/span>"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

13. March 2025\u00a0 |\u00a0 Tech Insights by Pavol Mr\u00e1z\u00a0 |\u00a0\u00a0<\/strong>CTO:\u00a0<\/span><\/span>My favorite C# features\u00a0<\/span>in real world use cases<\/span><\/p>

Introduction<\/h1>

I have read a ton of articles about someone\u2019s favorite C# language features on the Internet (especially on medium.com<\/a><\/span>) and some of them are really good and inspiring. I\u00a0have decided that I\u00a0might add two cents to the discussion, and this is my take on the subject. It is a\u00a0little bit different than the others, because I present real-world usage patterns, stemmed from our large code base (980+ KLOC) that is undergoing continuous development for more than nine years now (January, 2025). The code base is kind of a modular monolith<\/a> <\/span>comprised of several business applications, APIs, as well as some reusable functionality in the form of NuGet packages.<\/p>

In the discussion and code examples below, I have renamed some of the code artifacts, but the actual usage patterns remained intact. I have not tried to restate what the official documentation says, instead, I am providing links to its relevant sections. I\u00a0emphasize here that these are my subjective opinions, and not all my colleagues agree with me 100%.<\/p>

Field keyword<\/h1>

The contextual field keyword<\/a><\/span> can be used in property accessors to access the compiler-generated backing field of a property. We have been using it mostly to add validation to property setters implemented originally as auto-properties<\/a><\/span>. For example, we had this code before introducing the field keyword:<\/p>

class Person\n{\n public string Name { get; set; }\n}<\/code><\/pre>
After gradually introducing nullability to our code base, we were able to add property setter validation easily using the field keyword like this:<\/p>
class Person\n{\n public string Name { get; set { field = value ?? throw new ArgumentNullException(nameof(value)); } } = \"\";\n}<\/code><\/pre>
Please note that the official documentation<\/a><\/span> says that:<\/p>
\u201cThe field keyword is a preview feature in C# 13. You must be using .NET 9 and set your <LangVersion> element to preview in your project file in order to use the field contextual keyword.\u201d<\/strong><\/p>
However, we have been using it in projects targeting netstandard2.0 without problems just with the <LangVersion>preview<\/LangVersion> property set in .csproj (or Directory.Build.props file). This is understandable, because the field keyword is just a syntactic sugar allowing us to access the backing field without needing to know the actual compiler-generated mangled name as this gist<\/a><\/span> from sharplab.io<\/a><\/span> illustrates.<\/p>
Bonus chatter:<\/strong> First time I have used this feature, I wrote the code this way (note the property name in the setter):<\/p>
class Person\n{\n public string Name { get; set { Name = value ?? throw new ArgumentNullException(nameof(value)); } } = \"\";\n}<\/code><\/pre>
Neither the compiler nor any of the analyzers warned me, so I realized the mistake only after running the program and getting an StackOverflowException upon the very first Name property assignment. Now it is obvious that referencing the Name property inside the property setter method creates infinite recursion and I honestly do not know, what led me to write it that way.<\/p>
\"\"<\/p>
Pattern matching and switch expressions<\/h1>
This feature was first introduced in C# version 7.0<\/a><\/span> but since then, it has been gradually enhanced in almost all subsequent releases, including switch expressions<\/a><\/span> in C# version 8.0<\/a><\/span>. We have been using it mostly when working with enums, because the compiler ensures that we always cover all possible enum values (the switch expression is exhaustive as they call it). All but one of the usage patterns I have found use constant pattern<\/a><\/span> matching mapping from enum to some other value. For example, mapping from MqttNetLogLevel (from the excellent MQTTnet<\/a><\/span> library) to Microsoft\u2019s standard LogLevel:<\/p>
using Microsoft.Extensions.Logging;\nusing MQTTnet.Diagnostics;\n...\nLogLevel netLogLevel = logLevel switch\n{\n MqttNetLogLevel.Error => LogLevel.Error,\n MqttNetLogLevel.Warning => LogLevel.Warning,\n MqttNetLogLevel.Info => LogLevel.Information,\n MqttNetLogLevel.Verbose => LogLevel.Trace,\n _ => LogLevel.Debug\n};<\/code><\/pre>
The exhaustive mapping can be illustrated by omitting the last line with the discard expression \u201c_ => LogLevel.Debug\u201d. The then complains with a clear explanation: error CS8524: <\/strong>The switch expression does not handle some values of its input type (it is not exhaustive) involving an unnamed enum value. For example, the pattern ‚(MQTTnet.Diagnostics.MqttNetLogLevel)4‘ is not covered.<\/p>
The only other switch expression not using the constant pattern over enum, but based on a relational pattern matching<\/a><\/span> expression I found in the code base was in a MAUI<\/a><\/span> Android application. The application uses GPS for location tracking and maps the horizontal location accuracy<\/a><\/span> from meters to application-defined enumeration like this:<\/p>
public enum GpsLocationQuality\n{\n  Unknown = 0,\n  Poor = 1,\n  Good = 2,\n  Excellent = 3\n}\n...\nAndroid.Locations.Location location = <get location from ILocationListener>\nGpsLocationQuality quality = location.Accuracy switch\n{\n  <= 0 => GpsLocationQuality.Unknown,\n  < 5 => GpsLocationQuality.Excellent,\n  <= 15 => GpsLocationQuality.Good,\n  _ => GpsLocationQuality.Poor\n};<\/code><\/pre>
Please note that when we omit the last discard expression, the compiler still enforces the exhaustive mapping by giving us the following error:<\/p>
error CS8509: The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern '15.000001F' is not covered<\/code><\/pre>
Raw string literals<\/h1>
The Raw string literals<\/a><\/span> feature was introduced in C# 11 and I did find just one use case in our code base that I have actually implemented myself \ud83d\ude0a. It was as a portion of integration test suite for legacy SOAP asmx API that was migrated to ASP.NET Core (using the excellent SoapCore<\/a> <\/span>package). I have used a testing approach similar to what Michael feathers calls \u201ccharacterization testing\u201d in his excellent book \u201cWorking Effectively with Legacy Code<\/a><\/span>\u201d:<\/p>