var w C# bez tajemnic - kiedy używać, a kiedy nie?

Gdy deklaracja zmiennej zaczyna wyglądać jak ściana nazw typów, var potrafi wyraźnie poprawić czytelność kodu. Problem w tym, że wiele osób nadal myli go z typowaniem dynamicznym albo używa bez zastanowienia. Wyjaśniam, jak działa var w C#, kiedy warto po niego sięgać, gdzie pojawiają się ograniczenia oraz czym różni się od jawnego typu i konstrukcji new().

Co naprawdę oznacza var w C#

var jest tak zwanym słowem kontekstowym. Kompilator odczytuje wyrażenie po prawej stronie i na jego podstawie ustala konkretny typ zmiennej.

var age =  thirty;
var name = "Anna";
var price = 19.99m;

W powyższym przykładzie zmienne otrzymają odpowiednio typy int, string i decimal. Po kompilacji nie są to „zmienne bez typu”. Każda ma ściśle określony typ, którego nie można później zmienić.

var number = 10;
number = "dziesięć"; // błąd kompilacji

To najważniejsze rozróżnienie. var nie jest odpowiednikiem dynamic ani wariantu znanego z niektórych innych języków. Nie opóźnia sprawdzania typów do uruchomienia programu i nie wyłącza podpowiedzi IntelliSense. W praktyce zyskujemy krótszy zapis, ale nadal pracujemy z typowaniem statycznym.

Jak kompilator ustala typ zmiennej

Typ wynika bezpośrednio z wyrażenia inicjalizującego. Czasem rezultat jest banalnie oczywisty, a czasem trzeba zwrócić uwagę na szczegóły, takie jak typ literału albo wynik operatora.

var wholeNumber = 10;       // int
var bigNumber = 10L;        // long
var amount = 10.5;          // double
var money = 10.5m;          // decimal
var enabled = true;         // bool
var letters = new[] { 'a', 'b' }; // char[]

Literały mają swoje domyślne typy. Liczba całkowita bez sufiksu jest zwykle typu int, liczba dziesiętna bez sufiksu double, a dopisek m wymusza decimal. Ten detal ma znaczenie w obliczeniach finansowych, gdzie przypadkowe użycie double może prowadzić do niepożądanych zaokrągleń.

Mechanizm działa również dla kolekcji, klas i typów generycznych.

var users = new List();
var service = new EmailService();
var numbers = new[] { 1, 2, 3, 4 };

W tych przypadkach typ jest nadal konkretny: odpowiednio List, EmailService i int[]. Z mojego doświadczenia wynika, że właśnie przy długich typach generycznych var najczęściej poprawia odbiór kodu, bo czytelnik może skupić się na nazwie zmiennej i sposobie jej użycia.

Gdzie można używać var, a gdzie nie

Najczęściej spotkasz var przy zmiennych lokalnych deklarowanych wewnątrz metod. Można go też stosować w kilku konstrukcjach języka, o ile kompilator potrafi od razu ustalić typ.

for (var i = 0; i < 10; i++)
{
    Console.WriteLine(i);
}

foreach (var user in users)
{
    Console.WriteLine(user.Name);
}

using var stream = File.OpenRead("data.json");

if (int.TryParse(text, out var result))
{
    Console.WriteLine(result);
}

Nie można natomiast napisać deklaracji bez wartości początkowej ani przypisać bezpośrednio null.

var value;          // błąd
var empty = null;   // błąd
var callback = () => Console.WriteLine("OK"); // błąd

W ostatnim przypadku kompilator nie wie, jaki typ delegata ma zostać użyty. Trzeba wskazać go jawnie albo przypisać funkcję do wcześniej określonego typu.

Action callback = () => Console.WriteLine("OK");

var nie służy również do deklarowania pól klas, parametrów metod ani typów zwracanych.

public class ReportService
{
    private var reportName; // błąd

    public var CreateReport() // błąd
    {
        return ...;
    }
}

W publicznym API jawne typy są potrzebne, ponieważ opisują kontrakt klasy lub metody. Dzięki nim osoba korzystająca z biblioteki wie, czego oczekiwać bez analizowania implementacji.

Var a jawny typ i target-typed new

Najprostsze porównanie wygląda tak:

List names = new List();
var names = new List();

Obie wersje tworzą obiekt tego samego typu i mają takie samo zachowanie w czasie działania. Nie ma automatycznego zysku wydajności wynikającego z użycia var. Różnica dotyczy zapisu oraz tego, ile informacji o typie widzimy bezpośrednio w tej linii.

C# pozwala również pominąć typ po prawej stronie, gdy wynika on z lewej strony deklaracji.

List names = new();

To tak zwane target-typed new, czyli konstrukcja, w której new() korzysta z typu docelowego. Nie można jednak połączyć jej bezpośrednio z var.

var names = new(); // błąd, brak typu docelowego
var names = new List(); // poprawnie

To ograniczenie jest logiczne. W pierwszej wersji nie ma żadnej informacji, która pozwoliłaby kompilatorowi wybrać klasę do utworzenia. Samo var oznacza przecież „ustal typ z prawej strony”, a prawa strona nie podaje typu.

Kiedy użycie var poprawia kod

Najlepsza reguła nie brzmi „zawsze używaj var” ani „zawsze pokazuj typ”. Ja stosuję prostsze kryterium: jeżeli typ jest oczywisty z prawej strony, skrócony zapis zwykle pomaga.

var customer = new Customer();
var invoice = new Invoice();
var cancellationToken = new CancellationToken();

Nie muszę wtedy czytać tej samej informacji dwa razy. Nazwa klasy mówi wystarczająco dużo, a deklaracja nie jest obciążona powtórzeniem typu.

var jest szczególnie przydatny przy LINQ, gdzie pełny typ wyniku może być długi albo zależeć od sposobu wykonania zapytania.

var activeUsers = users
    .Where(user => user.IsActive)
    .OrderBy(user => user.Name)
    .ToList();

W tym miejscu jawny typ mógłby wyglądać tak:

List activeUsers = users
    .Where(user => user.IsActive)
    .OrderBy(user => user.Name)
    .ToList();

Obie wersje są poprawne, ale var ogranicza powtarzanie. Trzeba tylko uważać, gdy nie jest jasne, czy wynik jest materializowaną listą, IEnumerable, czy zapytaniem wykonywanym dopiero później. W takich miejscach jawny typ może być cenną informacją dla osoby utrzymującej kod.

Przeczytaj również: Generyki w C# i .NET - jak pisać bezpieczniejszy kod?

Typy anonimowe

Istnieje też przypadek, w którym var jest praktycznie konieczny. Typ anonimowy nie ma nazwy, którą można wpisać w kodzie.

var summary = new
{
    ProductName = "Klawiatura",
    Quantity = 2,
    Total = 399.98m
};

Console.WriteLine(summary.ProductName);

To dobre rozwiązanie dla tymczasowych projekcji w LINQ albo danych wykorzystywanych wyłącznie lokalnie. Nie nadaje się natomiast jako typ przekazywany przez publiczny interfejs. Jeśli obiekt ma opuścić metodę lub warstwę aplikacji, lepiej utworzyć nazwany rekord albo klasę.

Kiedy lepiej zrezygnować z var

Największy problem pojawia się wtedy, gdy typ nie wynika jasno z kodu. Przykład poniżej jest formalnie poprawny, ale wymaga od czytelnika przejścia do definicji metody.

var result = repository.GetData();

Czy result jest listą, słownikiem, pojedynczym rekordem, czy może obiektem reprezentującym wynik operacji? Sama linia tego nie wyjaśnia. W krytycznych miejscach jawny typ potrafi skrócić analizę kodu, nawet jeśli zapis jest dłuższy.

OperationResult result = repository.GetData();

Ostrożność przydaje się też przy typach prostych, gdy typ wpływa na znaczenie obliczenia.

var value = 1 / 2; // wynik typu int, czyli 0
double preciseValue = 1.0 / 2.0; // 0.5

Sam problem nie wynika z var, lecz z typów literałów i operatora dzielenia. Mimo to jawny typ może lepiej komunikować intencję. W kodzie finansowym, algorytmach i konwersjach jednostek nie zostawiałbym takich decyzji przypadkowi.

Nie używałbym var także wtedy, gdy zmienna ma reprezentować ważną abstrakcję.

IReadOnlyCollection users = LoadUsers();

Ten zapis mówi czytelnikowi coś więcej niż konkretna klasa zwrócona przez metodę. Pokazuje, że dalszy kod potrzebuje tylko kolekcji do odczytu. To różnica między ujawnieniem implementacji a opisaniem potrzebnego kontraktu.

Najczęstsze błędy w praktyce

Początkujący często zakładają, że var pozwala zmienić typ zmiennej w trakcie działania programu. Tak nie jest.

var data = "tekst";
data = 123; // błąd kompilacji

Drugi częsty błąd to używanie var bez inicjalizacji. Kompilator nie ma wtedy żadnego źródła informacji o typie.

var data; // brak informacji o typie

Trzeba też uważać na typ wyniku metod i przeciążenia. Zmiana wyrażenia po prawej stronie może zmienić typ zmiennej, a razem z nim dostępne właściwości, metody i przeciążenia.

var value = GetValue();
Console.WriteLine(value.Length);

Jeżeli GetValue() zacznie zwracać inny typ, kod może przestać się kompilować. To nie wada mechanizmu, tylko sygnał, że typ był istotną częścią założenia i być może powinien zostać zapisany jawnie.

Osobną pułapką są typy nullable. Jeśli metoda zwraca string?, użycie var nie usuwa informacji o możliwości wystąpienia wartości null. Kompilator nadal może zgłosić ostrzeżenie przy próbie użycia wyniku bez sprawdzenia.

var name = FindUserName();

Console.WriteLine(name.Length); // możliwe ostrzeżenie nullable

Dlatego var nie powinien być traktowany jako sposób na omijanie reguł bezpieczeństwa typów. On tylko skraca deklarację, a nie zmienia zasad języka.

Prosta reguła dla zespołu

Wspólny styl jest ważniejszy niż spór o jedyną słuszną wersję. Dobrze działają reguły oparte na czytelności, na przykład następujące:

• używaj var, gdy typ jest oczywisty z inicjalizatora,
• zostaw jawny typ, gdy pokazuje ważną abstrakcję albo intencję,
• stosuj var przy typach anonimowych i skomplikowanych wynikach LINQ,
• nie używaj go jako zamiennika dla dynamic,
• konfiguruj analizatory i formatowanie, aby cały projekt trzymał jedną konwencję.

Nie traktowałbym też długości typu jako jedynego kryterium. Czasem długa deklaracja jest ceną za jasność, a czasem tylko powtarza informację, którą i tak natychmiast widać.

Najpraktyczniejszy test jest prosty: zasłoń prawą stronę deklaracji i przeczytaj samą zmienną. Jeśli bez typu trudno zrozumieć, czym ona jest, jawna deklaracja prawdopodobnie będzie lepsza. Jeśli konstruktor albo wyrażenie mówi wszystko, var upraszcza kod bez utraty znaczenia.

Var jako skrót, nie ukrywanie typów

var w C# oznacza automatyczne ustalenie typu podczas kompilacji. Nie wprowadza dynamicznego typowania, nie daje zmiennej specjalnych możliwości i nie wpływa samodzielnie na wydajność programu.

Najwięcej zysku daje przy oczywistych obiektach, typach generycznych, pętlach, zapytaniach LINQ i typach anonimowych. Gdy typ wyraża kontrakt, ważną abstrakcję albo zamiar obliczenia, jawny zapis często będzie czytelniejszy.

Traktuję tę konstrukcję jak narzędzie redakcyjne dla kodu. Dobrze użyta usuwa szum, ale użyta automatycznie potrafi ukryć informację, której kolejny programista będzie potrzebował najbardziej.