W praktyce c# 10 to wersja, która bardziej odchudza codzienną pracę niż robi rewolucję w całym języku. Dostajesz mniej powtarzanego kodu, prostsze pliki z przestrzeniami nazw i kilka usprawnień w strukturach, lambdach oraz interpolowanych stringach. To ważne zwłaszcza wtedy, gdy tworzysz nowe projekty albo porządkujesz starszy kod po migracji na nowszy .NET.
Najważniejsze zmiany to mniej boilerplate'u i lepsza praca z typami danych
- C# 10 został wydany razem z .NET 6 i skupia się na uproszczeniu składni oraz ergonomii pracy.
- Najbardziej odczuwalne zmiany to global using, file-scoped namespaces, record structs i wygodniejsze lambdy.
- W projektach z dużą liczbą modeli i małych obiektów wartościowych ta wersja szybko daje porządek w kodzie.
- Interpolated string handlers mogą pomóc w gorących ścieżkach, np. logowaniu, ale nie są darmowym przyspieszeniem wszystkiego.
- Jeśli utrzymujesz starszy kod, część zmian warto wprowadzać stopniowo, a nie hurtowo.
Co wnosi ta wersja i gdzie naprawdę czuć różnicę
Według dokumentacji Microsoft Learn ta wersja języka idzie w stronę mniejszej ceremonii, lepszej czytelności i kilku realnych usprawnień wydajnościowych. W codziennej pracy nie chodzi jednak o to, żeby użyć każdej nowości naraz, tylko o to, by wiedzieć, które elementy naprawdę skracają drogę od pomysłu do działającego kodu.
| Zmiana | Co daje w praktyce | Kiedy warto | Na co uważać |
|---|---|---|---|
| Global using directives | Mniej powtórzeń na górze plików i mniej hałasu w importach | Duże rozwiązania z wieloma wspólnymi przestrzeniami nazw | Łatwo ukryć zależności, jeśli wrzuci się tam wszystko bez dyscypliny |
| File-scoped namespaces | Krótsze pliki i mniej wcięć | Większość plików, w których jest jeden namespace | Nie pasuje do plików z kilkoma przestrzeniami nazw |
| Record structs | Semantyka wartości plus czytelna składnia rekordów | Małe obiekty domenowe, DTO, punkty, zakresy, proste modele danych | Duże struktury kopiują się drożej niż klasy |
| Lambdy | Mniej szumu przy inferencji typu, typie zwrotnym i atrybutach | LINQ, mapowania, delegaty, drobne API funkcyjne | Nie każde wyrażenie da się jednoznacznie wywnioskować |
| Extended property patterns | Krótsze warunki na zagnieżdżonych danych | Walidacja, reguły biznesowe, switch expression | Przy przesadnym zagęszczeniu czytelność może spaść |
| Interpolated string handlers | Mniej pracy przy tworzeniu stringów w gorących ścieżkach | Logowanie, formatowanie, API, które potrafi pominąć zbędne obliczenia | Korzyść zależy od wsparcia po stronie biblioteki |
Największa wartość tej wersji nie leży w jednej spektakularnej funkcji, tylko w zestawie małych usprawnień, które razem robią z kodu coś wyraźnie lżejszego. Najpierw warto uporządkować szkielet projektu, bo właśnie tam efekt widać od razu.
Global using i file-scoped namespaces upraszczają szkielet projektu
Jeśli patrzę na realny repozytorium, właśnie tutaj najszybciej widać efekt C# 10. Znikają powtarzane dyrektywy using, pliki przestają tonąć w nawiasach, a czytelnik od razu widzi, z jaką przestrzenią nazw pracuje dany plik.
Global using
global using pozwala zadeklarować import raz i używać go w całym projekcie. W praktyce wiele zespołów trzyma takie wpisy w osobnym pliku, na przykład GlobalUsings.cs, żeby centralnie zarządzać wspólnymi importami.
global using System;
global using System.Collections.Generic;
global using System.Linq;To rozwiązanie dobrze działa dla naprawdę wspólnych przestrzeni nazw, takich jak System, System.Linq czy System.Text.Json. Ja nie wrzucałbym tam wszystkiego bez selekcji, bo zbyt szerokie globalne importy szybko zaciemniają zależności między plikami.
File-scoped namespace
File-scoped namespace skraca deklarację przestrzeni nazw do jednej linii i usuwa dodatkowe zagnieżdżenie. To drobiazg, ale w projekcie z setkami plików robi zauważalną różnicę w odbiorze kodu.
namespace MyApp.Models;
public class Customer
{
public string Name { get; init; } = string.Empty;
public string? Email { get; init; }
}Ten styl najlepiej pasuje do plików, w których jest jedna przestrzeń nazw i zwykle jeden główny typ. Jeśli plik jest nietypowy, zawiera generowany kod albo kilka odrębnych sekcji, klasyczne nawiasy nadal bywają rozsądniejszym wyborem. Gdy szkielet projektu jest już lżejszy, łatwiej przejść do typów danych, gdzie ta wersja daje bardziej merytoryczny niż kosmetyczny zysk.
Record struct sprawdza się tam, gdzie liczy się wartość, a nie tożsamość
To chyba najpraktyczniejsza nowość dla zespołów, które modelują dane wprost z domeny. record struct łączy semantykę wartości ze składnią rekordów, więc dostajesz porównywanie po wartościach, czytelne ToString() i krótszą deklarację typu.
| Typ | Semantyka | Najlepsze zastosowanie | Ryzyko |
|---|---|---|---|
class |
Tożsamość obiektu | Encje, obiekty z życiem i zachowaniem, domena z relacjami | Więcej ceremonii przy prostych data objectach |
struct |
Wartość | Małe, zwarte dane, np. punkty, zakresy, proste parametry | Brak wygody rekordów i łatwość przypadkowego kopiowania |
record struct |
Wartość + wygody rekordów | Małe obiekty wartościowe z porównaniem po danych | Duże struktury mogą być mniej opłacalne niż klasy |
public readonly record struct Point(int X, int Y);
var p1 = new Point(10, 20);
var p2 = p1 with { X = 15 };W takim układzie dostajesz zwięzły model danych i wygodne kopiowanie z modyfikacją tylko jednego pola. To działa świetnie dla małych, stabilnych wartości, ale nie traktuję tego jako uniwersalnego zamiennika dla klas. Jeśli typ rośnie albo zaczyna przenosić zbyt dużo stanu, przewaga składniowa szybko przestaje rekompensować koszt kopii.
public struct ConnectionSettings
{
public string? Host { get; set; }
public int Port { get; set; }
public ConnectionSettings()
{
Host = "localhost";
Port = 8080;
}
}Tutaj ważny jest szczegół, o którym łatwo zapomnieć: new ConnectionSettings() wywoła konstruktor, ale default(ConnectionSettings) go ominie i ustawi pola na wartości domyślne. W praktyce oznacza to, że przy strukturach trzeba pilnować różnicy między obiektem utworzonym przez konstruktor a takim, który powstał przez zero-inicjalizację. To właśnie ten niuans najczęściej robi później problemy w utrzymaniu. Kiedy dane są już dobrze opisane typami, naturalnie wychodzi następny krok: uproszczenie logiki warunkowej i funkcji zwrotnych.
Lambda i patterny są krótsze, ale wciąż czytelne
W C# 10 wyraźnie widać, że język chce lepiej wspierać kod funkcyjny i walidację zagnieżdżonych danych. Dla mnie najważniejsze są trzy rzeczy: naturalny typ lambdy, jawny typ zwrotu oraz rozszerzone wzorce właściwości.
Naturalny typ lambdy
Komórka kompilatora potrafi teraz lepiej wywnioskować typ delegata z samej lambdy albo z pojedynczej grupy metod. Dzięki temu część deklaracji staje się krótsza, a kod mniej przypomina ręczne dopisywanie szablonu.
var parse = (string s) => int.Parse(s);
object alsoParse = (string s) => int.Parse(s);W pierwszym przykładzie kompilator sam potrafi dopasować odpowiedni delegat. To pomaga zwłaszcza tam, gdzie lambda jest przekazywana dalej albo od razu trafia do var. Jeśli jednak typów wejściowych brakuje albo przeciążenia są zbyt podobne, nadal trzeba podać więcej informacji ręcznie.
Jawny typ zwrotu i atrybuty
Druga rzecz to możliwość dopisania typu zwrotnego przed parametrami lambdy. To przydaje się wtedy, gdy inferencja nie radzi sobie jednoznacznie albo gdy chcę, żeby zamiast domysłów kod mówił wprost, co zwracam.
var choose = object (bool b) => b ? 1 : "two";
var concat = ([DisallowNull] string a, [DisallowNull] string b) => a + b;Atrybuty na lambdach są przede wszystkim sygnałem dla analizatorów i narzędzi statycznych, a nie magią zmieniającą samo wywołanie. To dobra rzecz, bo można doprecyzować kontrakt funkcji bez rozbijania jej na osobną metodę, ale nie traktuję tego jako ozdoby składniowej. Jeśli atrybut niczego nie wnosi do czytelności albo analizy, po prostu go nie dodaję.
Przeczytaj również: Język C - Czy nadal ma sens? Przewodnik dla programistów
Rozszerzone wzorce właściwości
Tu zysk jest bardzo praktyczny: zamiast rozbijać obiekt na kilka zmiennych pomocniczych, można sprawdzić zagnieżdżone pola bezpośrednio w warunku. W codziennym kodzie walidacyjnym to zmniejsza liczbę kroków pośrednich.
if (order is { Customer.Address.City: "Warszawa", Total: > 200 })
{
// ...
}Taki zapis jest szczególnie wygodny w regułach biznesowych i switch expression, bo skraca drogę od struktury danych do warunku decyzyjnego. Jeśli jednak warunek zaczyna być zbyt długi, lepiej wrócić do kilku czytelnych kroków niż budować syntaktycznie gęsty fragment. Gdy logika jest już czytelna, kolejnym miejscem do optymalizacji stają się napisy, zwłaszcza w logowaniu i formatowaniu.
Interpolowane stringi są nie tylko wygodniejsze, ale też tańsze w wykonaniu
Tu wchodzi obszar, który zwykle interesuje mnie dopiero wtedy, gdy kod trafia na gorącą ścieżkę. C# 10 pozwala tworzyć const string z interpolacją, o ile wszystkie fragmenty są stałymi stringami, a interpolated string handlers dają bibliotekom szansę przerwać pracę, zanim powstanie cały tekst.
const string Prefix = "api";
const string Route = $"{Prefix}/v1";To brzmi jak drobiazg, ale w miejscach, gdzie składane są stałe etykiety, tagi albo identyfikatory, potrafi uprościć kod bez utraty semantyki. Nie wszystkie interpolacje da się jednak podnieść do poziomu stałej, więc to rozwiązanie ma wyraźne granice. Jeśli któryś z fragmentów nie jest stały, kompilator nie zrobi z tego const.
Drugi mechanizm jest bardziej interesujący z punktu widzenia wydajności. Interpolated string handlers pozwalają API zdecydować, czy w ogóle opłaca się budować końcowy napis. Najbardziej oczywisty scenariusz to logowanie: jeśli poziom logu jest wyłączony, nie ma sensu składać komunikatu, liczyć kosztownych fragmentów ani formatować tekstu, który i tak nie zostanie użyty.
To jednak nie jest uniwersalny przyspieszacz. Korzyść pojawia się dopiero wtedy, gdy metoda lub biblioteka naprawdę obsługuje handler, a nie zwykły string. Dlatego w praktyce sprawdzam to tam, gdzie koszt formatowania jest realny, a nie tylko teoretyczny. W prostym kodzie aplikacyjnym zwykłe $"..." nadal bywa najczytelniejszym wyborem. Kiedy mechanika języka jest już jasna, zostaje pytanie najważniejsze z punktu widzenia zespołu: jak wprowadzić te zmiany bez rozbijania całej bazy kodu.
Jak wdrożyć tę wersję w istniejącym zespole bez chaosu
W 2026 najzdrowiej działa podejście etapowe. Najpierw aktualizuję narzędzia i ustawienia kompilacji, potem porządkuję styl plików, a dopiero na końcu sięgam po bardziej specyficzne elementy, takie jak rekordowe struktury czy string handlers.
- Ustal jeden styl namespace'ów dla repozytorium i nie mieszaj go w tym samym module.
- Przenieś często używane importy do
GlobalUsings.cs, ale zostaw tam tylko rzeczy naprawdę wspólne. - Stosuj
record structdla małych, stabilnych wartości, a nie dla rozbudowanych encji. - Sprawdzaj zysk z interpolated string handlers tam, gdzie faktycznie masz koszt formatowania lub logowania.
- Nie migruj wszystkiego na siłę: starszy kod często lepiej wygląda po kilku dobrze dobranych zmianach niż po pełnym rewrite.
W praktyce najlepiej zaczynać od nowych plików i nowych modułów, bo tam łatwiej utrzymać spójność bez konfliktu ze starym stylem. Jeśli projekt ma być wspierany przez starsze środowiska albo różne wersje IDE, warto też pilnować ustawień wersji języka i nie zakładać, że każdy członek zespołu zobaczy ten sam zestaw możliwości. Jeśli mam wskazać jedną praktyczną lekcję z tej wersji, to jest nią dyscyplina w redukowaniu szumu. C# 10 nie zmienia tego, jak projektujesz system, ale usuwa sporo powtarzalności z plików, modeli i lambd, przez co kod szybciej się czyta i łatwiej utrzymuje.
