10 Najczęstszych Błędów w C# (i Jak Ich Unikać)

Początki nauki programowania w C# to ekscytująca przygoda, ale każdy junior prędzej czy później natrafi na typowe pułapki. Warto poznać je zawczasu – pozwoli to oszczędzić sporo frustracji i czasu. W tym artykule zebrałem 10 najczęstszych błędów popełnianych przez początkujących programistów C# oraz wskazówki, jak ich unikać. Dzięki temu łatwiej wejdziesz na dobrą ścieżkę pisania czystego i poprawnego kodu.

1. Mylenie typów wartościowych i referencyjnych

struct Point 
{ 
    public int X; 
}

Point p1 = new Point(); 
p1.X = 5;

Point p2 = p1;      /* kopia wartości p1 */
p2.X = 10;

Console.WriteLine(p1.X);  /* Wypisze 5, bo p1 pozostał niezmieniony */

2. Brak sprawdzania wartości null (NullReferenceException)

NullReferenceException to chyba najbardziej klasyczny błąd w C#. Występuje, gdy próbujesz użyć obiektu, który jest null (czyli tak naprawdę nie został utworzony). Przykładowo wywołanie metody na niezainicjowanym obiekcie spowoduje taki wyjątek. Dla zobrazowania:

string tekst = null;
Console.WriteLine(tekst.Length);  /* Błąd: tekst jest null, nie ma  właściwości Length */

Jak widać, próba odwołania się do tekst.Length skończy się rzuceniem wyjątku: "Object reference not set to an instance of an object". Początkujący często zapominają sprawdzić, czy zmienna nie jest null, zanim jej użyją.

Jak unikać: Zawsze upewniaj się, że obiekt jest zainicjalizowany przed użyciem. W razie wątpliwości dodaj sprawdzenie: if (tekst != null) {...}. Możesz też skorzystać z ułatwień składniowych, takich jak operator ?. (null-conditional), który bezpiecznie przerwie wywołanie, jeśli obiekt jest null. Przykład: Console.WriteLine(tekst?.Length); – wypisze długość tekstu lub null, ale nie rzuci wyjątku. Pamiętaj, że w nowoczesnym C# kompilator oferuje tzw. "nullable reference types" – ostrzega on przed miejscami, gdzie może pojawić się null. Nie ignoruj tych ostrzeżeń (więcej o tym w punkcie 7) – są po to, by pomóc Ci wyłapać NullReferenceException zanim uruchomisz program.

3. Błędy off-by-one i wyjście poza zakres tablicy

Błędy typu off-by-one (błędy przesunięcia o jeden) to pomyłki w liczeniu indeksów lub iteracji pętli o jeden w tę czy tamtą stronę. Typowym rezultatem jest IndexOutOfRangeException – wyjątek zgłaszany, gdy próbujesz odwołać się do indeksu tablicy lub listy spoza jej zakresu. Przykład: masz tablicę 5 elementów, indeksy dostępne to 0..4, ale pomylisz warunek pętli i spróbujesz odczytać indeks 5.

int[] liczby = { 1, 2, 3 };
for (int i = 0; i <= liczby.Length; i++)
{
    Console.WriteLine(liczby[i]);  /* IndexOutOfRangeException, gdy i == 3 */
}

W powyższej pętli warunek powinien być i < liczby.Length zamiast <=. Taka drobna pomyłka sprawia, że ostatnia iteracja odwoła się do liczby[3], którego nie ma (bo są tylko indeksy 0,1,2).

Jak unikać: Zwracaj szczególną uwagę na warunki w pętlach. Często pomocne jest pisanie pętli w idiomie: for(int i = 0; i < kolekcja.Length; i++) – użycie < zamiast <= uchroni przed nadmiarową iteracją. Przy operacjach na indeksach zawsze myśl o tym, ile elementów faktycznie masz. Jeśli iterujesz po kolekcji (foreach), to takie błędy Cię ominą, bo nie operujesz bezpośrednio na indeksach. Gdy sam obliczasz indeks, upewnij się, że mieści się on w granicach (np. indeks lastIndex = length - 1 dla ostatniego elementu). W razie wątpliwości dodaj dodatkowe zabezpieczenie: sprawdzenie warunkiem if, czy indeks jest w dozwolonym zakresie, zanim użyjesz go do dostępu do tablicy.

4. Pomylenie przypisania z porównaniem (= vs ==)

To częsta wpadka początkujących, zwłaszcza jeśli wcześniej uczyli się języków pokroju C/C++ czy JavaScript. W instrukcjach warunkowych w C# do porównania używamy podwójnego znaku równości ==. Pojedynczy znak = służy do przypisywania wartości. Jeśli omyłkowo w if użyjesz jednego =, kompilator zwykle to wyłapie i zgłosi błąd (prócz sytuacji, gdy przypisujesz do zmiennej typu bool). Spójrz na przykład:

bool isValid = false;
if (isValid = true)
{
    Console.WriteLine("Dane są poprawne!");
}

Tutaj zamiast sprawdzić, czy isValid jest prawdziwy (== true), przez pomyłkę użyto operatora przypisania. W efekcie kod ustawia isValid na true, zawsze wchodzi do środka ifa i wypisuje komunikat niezależnie od wcześniejszej wartości flagi. Tego typu błąd jest trudny do zauważenia, bo składnia jest poprawna dla kompilatora, ale logika programu staje się błędna.

Jak unikać: Zapamiętaj zasadę: porównania używają ==, przypisania =. Jeśli zdarzy Ci się komunikat o nieużywanej wartości logicznej lub zauważysz, że warunek zawsze się wykonuje, sprawdź, czy nie pomyliłeś tych operatorów. Dobrym nawykiem jest porównywanie do stałych w sposób, który zasygnalizuje błąd kompilacji przy pomyłce. Na przykład zamiast if (isValid == true) pisz po prostu if (isValid) dla boola, a dla porównania do stałej liczbowej: if (5 == x) zamiast if (x == 5) – wtedy przypadkowe if (5 = x) zostanie wychwycone przez kompilator (bo nie można przypisać do literału).

5. Niezamykanie zasobów – brak użycia using

W C# mamy garbage collector, który zwalnia pamięć, ale nie zwalnia wszystkiego. Gdy korzystasz z zewnętrznych zasobów – plików, połączeń do bazy danych, strumieni itp. – musisz je sam zamknąć lub zwolnić. Początkujący często o tym zapominają. Na przykład otwierają plik do odczytu, ale nie zamykają go po zakończeniu pracy, albo tworzą połączenie z bazą danych i nie wywołują Close(). Skutek? Zasoby systemowe (uchwyty do plików, połączenia) się wyczerpują albo dane nie zostają zapisane poprawnie po zakończeniu programu.

Jak unikać: Zawsze gdy "otwierasz" jakiś zasób, upewnij się, że zostanie on zamknięty. Najprostszym i najbezpieczniejszym sposobem jest korzystanie z konstrukcji using, która automatycznie wywoła zwolnienie zasobu po wyjściu z bloku, nawet jeśli wystąpi wyjątek. Przykład poprawnego użycia pliku:

using (var reader = new StreamReader("dane.txt"))
{
    string zawartosc = reader.ReadToEnd();
    Console.WriteLine(zawartosc);
}  /* tutaj StreamReader zostanie automatycznie zamknięty (Dispose) */

Dzięki using nie musisz pamiętać o jawnym zamknięciu pliku – po wyjściu z bloku zasób zostanie zwolniony. Stosuj tę konstrukcję lub w ostateczności pamiętaj o wywołaniu Dispose()/Close() w finally. Dotyczy to m.in. obiektów typu FileStream, StreamReader, SqlConnection i wszystkich, które implementują IDisposable.

6. Brak odpowiedniej obsługi wyjątków

Program początkującego często "wykłada się" na pierwszym nieprzewidzianym błędzie, bo nie ma zaimplementowanej obsługi wyjątków. Na przykład kod zakłada istnienie pliku, poprawność danych wejściowych albo dostępność internetu – a gdy coś pójdzie nie tak, aplikacja od razu się zatrzymuje z błędem. Innym razem początkujący dodają blok try-catch, ale łapią ogólny wyjątek Exception i… nic z nim nie robią (ewentualnie wyświetlają nic niemówiący komunikat). Obie sytuacje są błędami.

Jak unikać: Poznaj podstawy obsługi wyjątków w C#. Używaj try-catch w miejscach, gdzie spodziewasz się problemów (operacje wejścia-wyjścia, połączenia sieciowe, baza danych itp.). W bloku catch reaguj adekwatnie – przynajmniej zaloguj błąd lub pokaż użytkownikowi komunikat, zamiast pozwolić programowi się wysypać bez słowa. Przykład:

try 
{
    var dane = File.ReadAllText("plik.txt");
    Console.WriteLine(dane);
}
catch (IOException ex)
{
    Console.WriteLine($"Błąd dostępu do pliku: {ex.Message}");
}

W powyższym kodzie przewidujemy błąd odczytu pliku i odpowiednio go obsługujemy. Unikaj zbyt ogólnego łapania wyjątków (np. tylko samo catch(Exception)), chyba że na samym wysokim poziomie aplikacji – wówczas i tak przynajmniej zapisz błąd do logów. Ważne jest też, by nie ignorować wyjątków – puste catch to bardzo zły nawyk. Lepiej już nie łapać wyjątku wcale niż złapać i nic z nim nie zrobić, bo wtedy błąd pozostaje ukryty.

7. Ignorowanie ostrzeżeń kompilatora

Kompilator C# (oraz narzędzia analizy kodu) są Twoimi sprzymierzeńcami. Często podkreślają potencjalne problemy w postaci ostrzeżeń (warnings). Początkujący programiści niestety mają tendencję do ignorowania tych żółtych komunikatów, skupiając się tylko na błędach (errors) uniemożliwiających kompilację. To błąd, bo wiele ostrzeżeń wskazuje na realne problemy lub ryzyka w kodzie. Przykłady: "zmienna jest zadeklarowana, ale nieużywana", "możliwa dereferencja null" (to właśnie kompilator ostrzegający przed NullReferenceException), czy "metoda jest przestarzała".

Jak unikać: Traktuj ostrzeżenia poważnie. Idealnie, dąż do tego, by projekt kompilował się bez ostrzeżeń. Jeśli pojawia się ostrzeżenie, przeczytaj je i zrozum, co sugeruje – często dzięki temu złapiesz błąd, zanim stanie się on poważny. Na przykład ostrzeżenie o możliwej wartości null przypomni Ci o sprawdzeniu zmiennej (patrz punkt 2), a ostrzeżenie o nieużywanej zmiennej może wskazywać, że zapomniałeś czegoś zaimplementować lub usunąć zbędny kod. Oczywiście zdarzają się fałszywe alarmy lub sytuacje, gdy świadomie ignorujemy ostrzeżenie – wtedy można je wyłączyć za pomocą atrybutów lub dyrektyw preprocesora, ale rób to tylko, gdy jesteś pewien, co robisz. Na początku lepiej założyć, że każde ostrzeżenie ma znaczenie.

8. Niewłaściwy dobór kolekcji i struktur danych

C# oferuje bogaty wybór kolekcji: tablice, listy (List<T>), słowniki (Dictionary<K,V>), kolejki, zestawy (HashSet), itp. Częstym błędem początkujących jest trzymanie się uparcie jednego typu kolekcji (np. tablic) tam, gdzie lepsza byłaby inna struktura danych. Na przykład: dynamicznie zmieniająca się lista elementów jest łatwiejsza w obsłudze jako List<T> niż jako tablica o stałym rozmiarze. Z kolei potrzeba szybkiego sprawdzania przynależności elementu do zbioru aż prosi się o użycie HashSet, zamiast każdorazowego przeszukiwania listy w pętli.

Inny przykład złego doboru to używanie przestarzałych typów jak ArrayList zamiast generycznego List<T> – początkujący mogą natknąć się na stary kod lub poradniki i nieświadomie zaimportować złe praktyki, męcząc się potem z rzutowaniami typów.

Jak unikać: Ucz się dostępnych struktur danych i ich przeznaczenia. 

Zastanów się, do czego potrzebujesz danej kolekcji: 
-Czy rozmiar ma się zmieniać? Użyj List<T> zamiast zwykłej tablicy. 
-Czy potrzebujesz par klucz-wartość do szybkiego wyszukiwania? Dictionary<K,V> będzie odpowiedni. 
-Czy interesuje Cię unikalność elementów? HashSet<T> automatycznie dba o unikalność i szybkie sprawdzanie zawartości. 
-Czy przetwarzasz dane sekwencyjnie w kolejności FIFO lub LIFO? Rozważ Queue<T> lub Stack<T>.

Dobór właściwej kolekcji sprawi, że kod będzie prostszy i wydajniejszy. Jeśli nie jesteś pewien, poszukaj w dokumentacji .NET opisu kolekcji – są tam wskazówki, kiedy której używać. Unikaj też powielania własnych struktur, które już istnieją – np. nie twórz własnej listy przez dynamiczne powiększanie tablicy, skoro masz List<T> pod ręką.

9. Nieefektywna konkatenacja stringów w pętli

Manipulacja tekstem to kolejna pułapka wydajnościowa. Łączenie (konkatenacja) stringów za pomocą operatora + w środku pętli może działać poprawnie dla małych danych, ale dla większych okaże się bardzo nieefektywne. W C# stringi są niemodyfikowalne (immutable) – każde użycie + tworzy nowy obiekt string. Jeśli więc w pętli 1000 razy dodajesz coś do tekstu, powstają setki lub tysiące zbędnych obiektów w pamięci, co drastycznie obniża wydajność.

Jak unikać: Gdy musisz zbudować duży łańcuch tekstowy iteracyjnie, użyj klasy StringBuilder (znajduje się w System.Text). StringBuilder został zaprojektowany do efektywnego budowania stringów. Przykład:

var sb = new StringBuilder();
for (int i = 0; i < 1000; i++)
{
    sb.Append("*");
}
string wynik = sb.ToString();

Taki kod zadziała dużo szybciej i zużyje mniej pamięci niż równoważny z wynik += "*". Jeśli konkatenacji jest niewiele (kilka do kilkunastu operacji), + jest w porządku – kompilator i tak optymalizuje to w tle. Ale przy większej liczbie operacji zdecydowanie postaw na StringBuilder. Unikniesz tym samym spowolnienia programu i niepotrzebnego zużycia pamięci.

10. Błędy w składni if – brak klamr lub zbędny średnik

Na koniec pułapka, która potrafi napsuć krwi: subtelny błąd składni przy instrukcji warunkowej if. Dwie najczęstsze odmiany to: zapomniane klamry przy złożonym bloku oraz dodatkowy średnik po if. Oba przypadki mogą spowodować, że kod w if-ie wykona się inaczej, niż zakładasz.


• Brak klamr: W C# jeśli pominiemy { } po if, to warunek dotyczy tylko najbliższej pojedynczej instrukcji. Mniej doświadczeni programiści mogą mylnie sądzić, że wcięcia czy nowa linia mają znaczenie – niestety nie.

Przykład:

if (x > 0) 
    Console.WriteLine("x jest dodatni");
    Console.WriteLine("Zakończono sprawdzanie.");

Tutaj druga WriteLine wykona się zawsze, niezależnie od warunku, bo nie jest objęta klamrami. Kod działa inaczej niż sugeruje formatowanie.


• Zbędny średnik: Jeśli po warunku przypadkiem wstawisz średnik, to zamykasz if natychmiast, tworząc pustą instrukcję.

Przykład:

if (x > 0);
{
    Console.WriteLine("x jest dodatni!");
}

Ten blok zawsze wypisze tekst, bo średnik zakończył instrukcję if. Warunek wpływa jedynie na ten pusty, nic nie robiący średnik, a następujący po nim blok { ... } wykona się niezależnie od if. Taki błąd jest trudny do zauważenia na pierwszy rzut oka, a skutkuje błędną logiką programu.

Jak unikać: Zawsze stosuj nawiasy klamrowe { } dla bloków kodu w if/else, nawet jeśli jest tam tylko jedna instrukcja. To wyeliminuje nieporozumienia związane z wcięciami i uchroni przed przypadkowym dodaniem nowej linijki poza zakresem warunku. Uważnie sprawdzaj też składnię – zwłaszcza po modyfikacjach kodu. Wiele edytorów i narzędzi linterskich potrafi ostrzec przed pustym if lub brakiem klamr – warto z nich korzystać. Dobrym nawykiem jest formatowanie kodu (np. automatyczne w Visual Studio poprzez Ctrl+K, Ctrl+D), co uwidoczni źle umiejscowione klamry lub średniki.

Podsumowanie

Popełnianie błędów to naturalna część nauki programowania. Kluczowe jest, aby wyciągać z nich wnioski. Poznając najczęstsze wpadki – od NullReferenceException po złe użycie operatorów – możesz świadomie ich unikać i szybciej robić postępy. Pamiętaj, że nawet doświadczeni programiści kiedyś je popełniali, ważne by stale się doskonalić.

Jeśli chcesz nauczyć się więcej dobrych praktyk i pewnie wkroczyć w świat C#/.NET, zapraszam Cię do mojego kompletnego szkolenia online "Zostań Programistą .NET" – to kompleksowy program (droga od zera do pracy jako młodszy programista C#/.NET w 3 miesiące), który pomoże Ci opanować fundamenty i uniknąć podobnych błędów w przyszłości. Powodzenia w kodowaniu.