Jak zacząć z C#: prosta aplikacja konsolowa i najważniejsze pojęcia na start

Od czego w ogóle zacząć naukę C# – realny obraz języka

C# w praktyce: gdzie ten język faktycznie się przydaje

C# jest językiem ogólnego przeznaczenia, ale to niewiele mówi początkującemu. W praktyce oznacza to, że ten sam język wykorzystasz do tworzenia bardzo różnych typów aplikacji. Jeden zestaw umiejętności pozwala budować:

• aplikacje desktopowe dla Windows (np. narzędzia biurowe, aplikacje do automatyzacji zadań, panele administracyjne),
• aplikacje webowe (backend w ASP.NET Core, API, panele administracyjne, systemy biznesowe),
• gry w silniku Unity (logika gry, systemy punktów, interakcje),
• narzędzia konsolowe do automatyzacji i skryptów (import danych, przetwarzanie plików, integracje),
• usługi i procesy działające w tle (np. serwisy Windows, mikroserwisy w chmurze).

Dla osoby startującej od zera istotne jest głównie to, że podstawy są wspólne. Niezależnie, czy w przyszłości pójdziesz w gry, w web, czy w aplikacje biurowe, warto zacząć od prostych aplikacji konsolowych. Tam najłatwiej zobaczyć, co naprawdę robi kod, bez rozpraszania się interfejsem graficznym, HTML-em czy działaniem przeglądarki.

Co naprawdę jest trudne na początku, a co tylko groźnie brzmi

Świat C# i .NET ma sporo pojęć, które brzmią technicznie i zniechęcają początkujących: CLR, JIT, managed code, GC, assemblies, typy referencyjne, typy wartościowe. Duża część tego jest istotna dopiero po jakimś czasie. Na pierwsze tygodnie nauki wystarczy, jeśli:

• rozpoznasz te nazwy (żeby wiedzieć, że to nie „czarna magia”, tylko konkretne mechanizmy),
• zrozumiesz w bardzo dużym uproszczeniu, co robią (np. CLR to „maszyna” odpalająca kod C#),
• nie będziesz się ich bać, ale też nie będziesz próbować zrozumieć wszystkiego na raz.

Dużo trudniejsze na początku są rzeczy pozornie banalne: poprawne myślenie w krokach (algorytm), pilnowanie nazw zmiennych, średników i nawiasów, czytanie błędów kompilatora, rozumienie, co dokładnie dzieje się w pętli. To właśnie na tym etapie wiele osób rezygnuje, choć same pojęcia z dokumentacji wydają się im „teoretycznie jasne”.

Rozsądniejsze podejście: akceptować, że część terminów będzie w tle, a fokus trzymać na pisaniu i uruchamianiu małych programów. Po 10–20 małych ćwiczeniach pojęcia „z teorii” zaczynają naturalnie łączyć się w całość.

Minimalny zestaw narzędzi na start bez przepłacania

Do pierwszych aplikacji konsolowych w C# wystarczą trzy elementy:

• .NET SDK – oficjalny zestaw narzędzi (kompilator, uruchamianie, szablony projektów),
• prosty edytor kodu (Visual Studio Code, Visual Studio Community, Rider w wersji trial – choć na start wcale nie musi to być Rider),
• wbudowany terminal lub konsola systemowa (PowerShell, cmd, terminal w macOS / Linux).

Nie ma potrzeby kupowania kursów, drogich IDE, wtyczek „przyspieszających naukę” czy subskrypcji chmury. Na pierwsze tygodnie liczy się:

• możliwość pisania kodu ze wsparciem podpowiedzi składni,
• łatwe uruchamianie programu,
• czytelny podgląd błędów kompilacji.

Visual Studio Community jest darmowe do zastosowań niekomercyjnych i zapewnia wszystko, czego potrzeba. Visual Studio Code jest lekkie i przenośne, ale wymaga kilku rozszerzeń. Na tym etapie to raczej wybór preferencji niż kwestia „jednego słusznego” narzędzia.

Co da się zrobić w samej konsoli i dlaczego to dobry start

Aplikacje konsolowe kojarzą się z czymś „archaicznym”, ale do nauki programowania są bardzo wygodne. Pozwalają:

• wczytywać dane od użytkownika (np. liczby, teksty),
• wypisywać komunikaty i wyniki obliczeń,
• tworzyć proste menu, pętle, kalkulatory, małe gry tekstowe,
• obsługiwać pliki (zapisywać wyniki do pliku, wczytywać dane wejściowe).

To w zupełności wystarcza na pierwsze tygodnie, a często i miesiące nauki. Dodatkowy plus: jeśli coś nie działa, widać to od razu w konsoli. Nie trzeba zgadywać, czy problem leży w kodzie, w przeglądarce, czy w HTML/CSS.

Dopiero gdy swobodnie korzystasz z warunków, pętli, metod i prostych struktur danych (tablice, listy), sensownie jest przechodzić do frontendu, API czy Unity. W przeciwnym razie większość frustracji wynika z wielu nakładających się warstw technologii, a nie z samego języka C#.

Krótko o różnicach: C#, C, C++ – aby nie mieszać pojęć

Podobna nazwa to częste źródło nieporozumień. Najważniejsze różnice w skrócie:

C# jest językiem zarządzanym, co oznacza, że wiele niskopoziomowych detali (alokacja i zwalnianie pamięci) obsługuje środowisko uruchomieniowe .NET. Dla początkujących to plus: łatwiej skupić się na logice programu. Dopiero później wchodzi się w optymalizację, wydajność czy specyfikę działania garbage collectora.

Środowisko pracy: instalacja, konfiguracja i pierwszy kontakt z narzędziami

Wybór środowiska: Visual Studio, VS Code, Rider

Decyzja o wyborze środowiska bywa zaskakująco ważna. Zbyt ciężkie IDE potrafi przytłoczyć, zbyt proste – utrudnić pracę. Najpopularniejsze opcje dla C# to:

• Visual Studio Community (Windows, darmowe) – kompletne IDE, pełna integracja z .NET, dobry debuger, kreatory projektów. Minusy: spory rozmiar, wolniejsze na słabszych komputerach.
• Visual Studio Code (Windows, macOS, Linux, darmowe) – lekki edytor z pluginami. Po doinstalowaniu rozszerzeń (C#, C# Dev Kit) pozwala wygodnie pracować, choć debugowanie i projekty bywają początkowo mniej intuicyjne.
• Rider (JetBrains, płatny) – jedno z najlepszych IDE do C#, ale to wydatek. Dla początkujących to bardziej ciekawostka niż konieczność, szczególnie że Visual Studio Community spełnia większość potrzeb.

Na start najrozsądniej wybrać Visual Studio Community na Windows lub VS Code na macOS / Linux. Nie ma sensu spędzać dni na porównywaniu narzędzi, skoro i tak największą barierą będzie samo programowanie.

Instalacja .NET SDK i weryfikacja konfiguracji

.NET SDK to paczka zawierająca kompilator C#, narzędzia wiersza poleceń i podstawowe biblioteki. Bez niej nie uruchomisz ani jednego programu konsolowego. Kroki są proste:

1. Przejdź na oficjalną stronę .NET i pobierz najnowszą stabilną wersję .NET SDK dla swojego systemu.
2. Zainstaluj pakiet z domyślnymi ustawieniami.
3. Otwórz nowy terminal (PowerShell, cmd, terminal w macOS / Linux).
4. Wpisz:

   dotnet --version

Jeśli narzędzie zwróci numer wersji, SDK jest poprawnie zainstalowane. Jeśli pojawi się komunikat o nieznanym poleceniu, typowe przyczyny to:

• terminal był otwarty przed instalacją (zamknij i otwórz ponownie),
• instalacja wymagała restartu systemu,
• instalator nie dodał ścieżki do zmiennej środowiskowej PATH (w najnowszych wersjach zdarza się rzadko, ale nadal bywa).

Bez działającego polecenia dotnet większość kolejnych kroków się nie powiedzie, więc lepiej rozwiązać ten problem od razu, zamiast szukać winy w kodzie.

Tworzenie pierwszego projektu konsolowego z linii komend

Linia komend bywa pomijana przez początkujących, a to błąd. Narzędzie dotnet działa identycznie niezależnie od IDE, a część dokumentacji i materiałów przykładowych zakłada znajomość jego podstaw. Minimalny zestaw komend na start:

1. Wybierz katalog roboczy, np. C:ProjektyCSharp lub ~/projekty/csharp.
2. W terminalu przejdź do katalogu:

   cd C:ProjektyCSharp

3. Utwórz nowy projekt konsolowy:

   dotnet new console -n HelloWorld

4. Przejdź do katalogu projektu:

   cd HelloWorld

5. Uruchom program:

   dotnet run

Po tych krokach w terminalu powinna pojawić się linia „Hello, World!” lub jej odpowiednik w zależności od wersji szablonu. Jeżeli komenda dotnet new zgłasza błąd, często winny jest brak uprawnień do katalogu lub niepoprawnie zainstalowane SDK.

Tworzenie projektu z poziomu IDE i pierwsze uruchomienie

W Visual Studio Community proces wygląda trochę inaczej, ale rezultat jest taki sam:

1. Uruchom Visual Studio.
2. Wybierz opcję „Create a new project”.
3. Filtruj po „C#” i „Console” i wybierz „Console App”.
4. Ustaw nazwę projektu (np. HelloWorld) i lokalizację.
5. Potwierdź i poczekaj, aż projekt zostanie utworzony.
6. Naciśnij przycisk „Start” (zwykle zielony trójkąt) lub klawisz F5.

Powinna otworzyć się konsola z komunikatem „Hello, World!”. Visual Studio pod spodem używa tych samych narzędzi dotnet, ale chowa je za przyjaznym interfejsem. Na dłuższą metę przydaje się rozumieć oba światy: IDE i terminal.

Struktura wygenerowanego projektu konsolowego

Standardowy projekt konsolowy zawiera kilka plików, które początkowo mogą wydawać się losowe. Po utworzeniu projektu zobaczysz mniej więcej taki układ:

• HelloWorld.csproj – plik projektu, konfiguracja kompilacji (należy go mieć, ale na starcie można go nie dotykać),
• Program.cs – główny plik z kodem, który uruchamia się jako pierwszy,
• katalog obj – pliki pośrednie generowane przy kompilacji,
• katalog bin – wynik kompilacji: plik .dll lub .exe, zależnie od systemu i konfiguracji.

Dla początkującego jedynym plikiem, który trzeba edytować, jest zazwyczaj Program.cs. Katalogi bin i obj wygeneruje narzędzie, nie trzeba ich ręcznie modyfikować.

Ustawienia poprawiające komfort pracy

Nawet przy prostych projektach można sobie ułatwić życie kilkoma ustawieniami:

• Formatowanie kodu – w Visual Studio warto włączyć automatyczne formatowanie przy zapisie (Options → Text Editor → C# → Code Style),
• Czcionka – monospace (Consolas, Fira Code) z rozmiarem, który nie męczy oczu,
• Język komunikatów – komunikaty IDE po polsku są kuszące, ale dokumentacja, Stack Overflow i przykłady używają angielskich komunikatów błędów. Dlatego sensownie jest trzymać IDE po angielsku, szczególnie jeśli planujesz szukać rozwiązań problemów w sieci,
• Podpowiedzi Intellisense – nie wyłączać; na początku to wielka pomoc. Jeśli przeszkadzają, można minimalnie ograniczyć intensywność, ale całkowite wyłączenie raczej tylko utrudni naukę.

Pierwsza aplikacja konsolowa „Hello, World” krok po kroku

Minimalny kod „Hello, World” – co tam się właściwie dzieje

Po utworzeniu projektu w nowszych wersjach .NET w pliku Program.cs możesz zobaczyć bardzo krótki kod, np.:

Console.WriteLine("Hello, World!");

Wygląda to zaskakująco prosto, ale pod spodem dzieje się więcej. To tzw. top-level statements – mechanizm, który ukrywa przed początkującym część „ceremonii” związanej z klasami i metodą Main. Kompilator C# w rzeczywistości generuje coś w tym stylu:

public class Program
{
    public static void Main(string[] args)
    {
        Console.WriteLine("Hello, World!");
    }
}

Różnica jest tylko w wygodzie zapisu, a nie w działaniu. Kod z top-level statements nie tworzy „magicznego” programu – po prostu kompilator dopisuje brakujące elementy. Dlatego w starszych tutorialach można zobaczyć pełną wersję z klasą i metodą Main, a w nowszych – skróconą. Obie formy są poprawne.

Klasyczna wersja „Hello, World” z metodą Main

Dobrze jest znać również „tradycyjny” zapis, bo szybko pojawi się w innych przykładach. W tym celu można wyłączyć top-level statements (np. wstawiając własną klasę i metodę Main) i napisać:

using System;

namespace HelloWorld
{
    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
        }
    }
}

Ten kod składa się z kilku nowych elementów:

• using System; – informacja dla kompilatora, z których przestrzeni nazw ma korzystać (o tym niżej),
• namespace HelloWorld – logiczne „opakowanie” kodu, przydaje się w większych projektach,
• internal class Program – definicja klasy; program konsolowy zaczyna wykonywanie od jej metody Main,
• static void Main(string[] args) – punkt wejścia programu, metoda uruchamiana jako pierwsza.

W codziennej pracy zwykle nie myśli się o tym, że Main jest jak drzwi wejściowe do aplikacji. Ale przy próbie uruchamiania „losowych” fragmentów kodu bez tej metody szybko pojawiają się komunikaty o braku punktu wejścia.

Console.WriteLine – pierwsza interakcja z konsolą

Wywołanie:

Console.WriteLine("Hello, World!");

robi dokładnie jedną rzecz: wypisuje tekst i przechodzi do nowej linii. Console to klasa z biblioteki .NET odpowiadająca za komunikację z konsolą. WriteLine to metoda, która:

• przyjmuje wartość do wypisania (tekst, liczby, inne typy po konwersji),
• dodaje znak końca linii na końcu (dlatego kursor przeskakuje do nowej linijki).

Dla porównania, Console.Write nie dodaje znaku nowej linii, więc można wypisywać kilka elementów w tym samym wierszu:

Console.Write("Podaj imię: ");
Console.WriteLine("Jan");

Efekt w konsoli:

Podaj imię: Jan

Różnica niby drobna, ale w praktyce pomylenie Write z WriteLine psuje czytelność komunikatów wejścia/wyjścia.

Jak C# uruchamia kod: program, metoda Main i rola środowiska .NET

Rola metody Main jako punktu startowego

Żeby program w C# mógł się uruchomić, kompilator potrzebuje dokładnie jednej metody Main, która spełnia określone warunki. Typowe warianty to:

static void Main() { }

static void Main(string[] args) { }

static int Main() { return 0; }

static int Main(string[] args) { return 0; }

W aplikacjach konsolowych najczęściej stosuje się static void Main(string[] args) lub, korzystając z top-level statements, nawet nie pisze się jej ręcznie. Jeśli w projekcie pojawią się dwie metody Main w różnych klasach, kompilator zgłosi błąd „Program has more than one entry point” – w takim wypadku trzeba wskazać właściwą metodę w ustawieniach projektu.

Co robi .NET, gdy uruchamiasz aplikację

Cały proces uruchamiania w uproszczeniu wygląda tak:

1. Kompilujesz kod C# – kompilator tworzy zestaw (assembly), zwykle plik .dll lub .exe, zawierający IL (Intermediate Language), czyli pośredni język bajtowy.
2. Uruchamiasz program – środowisko .NET (CLR – Common Language Runtime) ładuje zestaw.
3. CLR wyszukuje metodę Main (lub generowany punkt wejścia przy top-level statements).
4. JIT (Just-In-Time compiler) tłumaczy IL na natywny kod maszynowy dla konkretnego procesora.
5. Program działa – CLR zarządza pamięcią, garbage collectorem, wyjątkami itd.

W codziennym kodowaniu rzadko zagląda się do IL czy JIT-a, ale świadomość, że C# nie jest kompilowany „prosto do maszynówki” jak C, pomaga zrozumieć niektóre różnice wydajnościowe i zachowania środowiska.

GC i zarządzana pamięć – dlaczego „new” nie wymaga delete

W C# obiekty tworzy się zwykle za pomocą new:

var lista = new List<int>();
var osoba = new Osoba();

W odróżnieniu od C/C++, nie wywołuje się delete czy free. Sprzątanie pamięci obsługuje garbage collector (GC). Działa to tak, że CLR okresowo sprawdza, które obiekty nie mają już żadnych referencji z działającego kodu, i zwalnia ich pamięć.

To ogromne ułatwienie, ale nie zwalnia całkowicie z myślenia. Kilka typowych pułapek:

• GC nie zwolni pamięci „natychmiast” po tym, gdy przestajesz używać obiektu – decyduje sam, kiedy przeprowadzić kolejną kolekcję,
• obiekty trzymane w statycznych polach lub w kolekcjach, do których stale coś dopisujesz, nie znikną tylko dlatego, że „o nich zapomniałeś”,
• brak dbałości o zwalnianie zasobów zewnętrznych (np. pliki, połączenia do bazy danych) potrafi zabić aplikację szybciej niż wycieki pamięci RAM.

Na poziomie prostych programów konsolowych najrozsądniej jest przyjąć, że GC „po prostu działa”, a do szczegółów wrócić, gdy zaczną się pojawiać bardziej skomplikowane scenariusze.

using i przestrzenie nazw – skąd się bierze Console

Instrukcja:

using System;

pojawia się u góry większości prostych plików. Bez niej kompilator nie wiedziałby, czym jest Console. Można to sprawdzić na żywo:

// bez 'using System;'
Console.WriteLine("Test"); // błąd kompilacji

Ale jeśli dopiszesz pełną nazwę typu ze ścieżką przestrzeni nazw, kod zadziała:

System.Console.WriteLine("Test");

using nie „importuje” kodu w sensie fizycznym; tylko pozwala pisać krócej. W większych projektach uniknięcie powtórzeń typu System.Collections.Generic.List<int> bez using System.Collections.Generic; byłoby dość uciążliwe.

Zmienne, typy danych i operatory – fundamenty, na których wszystko się opiera

Zmienne – nazwana przechowalnia na dane

Zmienne to etykiety, pod którymi program trzyma wartości. W C# każda zmienna ma typ. Przykład:

int wiek = 30;
string imie = "Jan";
bool czyAktywny = true;

Schemat deklaracji jest prosty:

<typ> <nazwa> = <wartość>;

Kilka praktycznych zasad na start:

• nazwy zmiennych zaczynaj małą literą i używaj notacji camelCase (liczbaUczniow),
• nie używaj polskich znaków mimo że kompilator je akceptuje – szybciej pojawią się problemy przy współpracy z innymi narzędziami,
• nadaj nazwę zgodną z przeznaczeniem: wiek mówi więcej niż x.

Typy proste (value types) – liczby, bool, char

Najczęściej używane typy w pierwszych programach:

• int – liczby całkowite (np. -10, 0, 42),
• double – liczby zmiennoprzecinkowe (np. 3.14, -0.5),
• bool – wartość logiczna: true lub false,
• char – pojedynczy znak (np. 'A', 'b', '1').

Przykłady użycia:

int iloscSztuk = 5;
double cena = 19.99;
bool czyZalogowany = false;
char separator = ':';

Te typy są przechowywane bezpośrednio „w miejscu zmiennej” (value types) – w odróżnieniu od typów referencyjnych, takich jak string czy własne klasy, gdzie zmienna przechowuje odnośnik (referencję) do danych w pamięci. Na początku różnica ma znaczenie głównie przy przekazywaniu do metod, ale z czasem zaczyna wpływać na wydajność i zachowanie kodu.

Tekst i typ string

Tekst reprezentuje typ string. Należy go zapisywać w cudzysłowach:

string powitanie = "Witaj w C#!";
string imie = "Anna";

Można łączyć teksty z innymi wartościami na kilka sposobów. Najczytelniejszy to interpolacja:

int wiek = 25;
string komunikat = $"Cześć, {imie}. Masz {wiek} lat.";
Console.WriteLine(komunikat);

Próby konkatenacji przez operator + działają, ale szybko stają się mało czytelne:

string zle = "Cześć, " + imie + ". Masz " + wiek + " lat.";

Dla prostych przykładów nie ma to większego znaczenia, jednak w projektach produkcyjnych interpolacja z reguły wygrywa czytelnością.

var – skrócony zapis, który też ma typ

Często pojawia się skrót:

var liczba = 10;
var tekst = "abc";

var nie oznacza „dowolny typ” ani „późne typowanie”. Kompilator statycznie ustala typ na podstawie przypisanej wartości. W powyższym przykładzie:

• liczba jest typu int,
• tekst jest typu string.

Jeśli nie ma wartości początkowej, var nie zadziała:

var x; // błąd – kompilator nie wie, jaki typ ma mieć x

Na początku lepiej nie nadużywać var. Jasne deklarowanie typów ułatwia czytanie kodu i zrozumienie błędów.

Operatory arytmetyczne i logiczne

Do operacji na liczbach używa się standardowych operatorów:

• + – dodawanie,
• - – odejmowanie,
• * – mnożenie,
• / – dzielenie,
• % – reszta z dzielenia (modulo).

Przykład:

int a = 7;
int b = 3;

int suma = a + b;        // 10
int roznica = a - b;     // 4
int iloczyn = a * b;     // 21
int iloraz = a / b;      // 2 (dzielenie całkowite)
int reszta = a % b;      // 1

Pułapka: przy dzieleniu dwóch int wynik też jest int – część ułamkowa zostaje obcięta. Jeśli potrzebne jest dzielenie „z przecinkiem”, przynajmniej jeden z operandów musi być typu zmiennoprzecinkowego:

double wynik = 7.0 / 3; // ok. 2.3333
double wynik2 = (double)a / b;

Do operacji logicznych używa się:

• && – i (AND),
• || – lub (OR),
• ! – negacja (NOT).

Przykład użycia w warunku:

bool czyPelnoletni = wiek >= 18;
bool czyMaPrawko = true;

if (czyPelnoletni && czyMaPrawko)
{
    Console.WriteLine("Może prowadzić samochód.");
}

Konwersje typów – jawne i niejawne

Niektóre typy można konwertować automatycznie, bez dodatkowego zapisu:

int x = 5;
double y = x; // niejawna konwersja z int do double

W drugą stronę, gdy istnieje ryzyko utraty danych, potrzebna jest konwersja jawna (rzutowanie):

Rzutowanie i konwersje liczbowo–tekstowe

Rzutowanie jawne przydaje się głównie przy typach liczbowych:

double d = 9.99;
int i = (int)d; // i = 9, część ułamkowa zostaje obcięta

To nie jest zaokrąglanie – po prostu odcięcie części po przecinku. Do normalnego zaokrąglania używa się metod z klasy Math:

double d = 9.99;
int zaokraglone = (int)Math.Round(d); // 10
int wDol = (int)Math.Floor(d);        // 9
int wGore = (int)Math.Ceiling(d);     // 10

Przy prostych aplikacjach konsolowych szybciej robi się konwersje między liczbami a tekstem. Do zamiany liczby na tekst zazwyczaj wystarczy ToString():

int liczba = 123;
string tekst = liczba.ToString(); // "123"

W drugą stronę wchodzi w grę int.Parse albo bezpieczniejszy wariant int.TryParse (do niego jeszcze wrócimy przy wczytywaniu tekstu z konsoli):

string tekst = "123";
int liczba = int.Parse(tekst); // założenie: tekst jest poprawną liczbą

Jeżeli tekst nie będzie poprawną liczbą (np. "abc"), int.Parse wyrzuci wyjątek. Przy danych od użytkownika to norma, więc w produkcyjnym kodzie zamiast „ufać” tekstowi, stosuje się TryParse.

Stałe – kiedy warto zablokować możliwość zmiany

Nie wszystkie wartości powinny być zmienne. Czasami to po prostu etykieta na niezmienny parametr:

const double StawkaVat = 0.23;
const int MaksLiczbaProb = 3;

const wymaga podania wartości w momencie deklaracji i nie pozwala jej później zmienić. Przy prostych skryptach to detal, ale przy większym kodzie ogranicza liczbę przypadkowych błędów i „magicznych liczb” rozsianych po projekcie.

Wczytywanie danych, instrukcje warunkowe i pętle – pierwsza logika programu

Wczytywanie tekstu z konsoli – Console.ReadLine

Bez interakcji z użytkownikiem konsolówka szybko staje się nudna. Podstawą komunikacji jest:

string? linia = Console.ReadLine();

Ta metoda zwraca tekst wpisany przez użytkownika (bez znaku Enter). W nowszych wersjach C# typ jest oznaczony jako string?, bo w szczególnych sytuacjach może zwrócić null (np. przy przekierowaniu strumienia we/wy).

Prosty dialog:

Console.Write("Podaj swoje imię: ");
string? imie = Console.ReadLine();

Console.WriteLine($"Cześć, {imie}!");

Jeśli nie chcesz jeszcze walczyć z null, w małych ćwiczeniach często spotyka się wymuszanie „nie-nullowalności” operatorem !:

string imie = Console.ReadLine()!; // zakładamy, że nie będzie null

To jednak świadome zaufanie do środowiska. W małych zadaniach konsolowych bywa akceptowalne, w kodzie robionym „na serio” wypada obsłużyć ewentualny brak danych.

Konwersja z tekstu na liczby – TryParse zamiast rzucania wyjątkami

Dane wpisywane z klawiatury są zawsze tekstem. Żeby policzyć sumę, średnią czy cokolwiek liczbowego, trzeba przekonwertować wejście na konkretny typ. Najprostszy wariant:

Console.Write("Podaj wiek: ");
string? tekst = Console.ReadLine();

int wiek = int.Parse(tekst!);  // założenie: użytkownik wpisze poprawną liczbę
Console.WriteLine($"Za rok będziesz mieć {wiek + 1} lat.");

To działa tylko przy „grzecznym” użytkowniku. Jedno literowe wpisanie i program się wywala. Rozsądniejsza wersja używa TryParse:

Console.Write("Podaj wiek: ");
string? tekst = Console.ReadLine();

bool sukces = int.TryParse(tekst, out int wiek);

if (!sukces)
{
    Console.WriteLine("To nie wygląda na poprawną liczbę całkowitą.");
}
else
{
    Console.WriteLine($"Za rok będziesz mieć {wiek + 1} lat.");
}

TryParse zwraca true, jeśli konwersja się udała, a wynik umieszcza w zmiennej wiek przekazanej przez out. To dość charakterystyczny wzorzec dla C# – często spotykany również przy datach (DateTime.TryParse) czy liczbach zmiennoprzecinkowych (double.TryParse).

Instrukcja if – rozgałęzienie na bazie warunku

Najprostsza forma sterowania logiką programu to if:

Console.Write("Podaj temperaturę w stopniach Celsjusza: ");
string? tekst = Console.ReadLine();

if (double.TryParse(tekst, out double temp))
{
    if (temp >= 0)
    {
        Console.WriteLine("Woda w tych warunkach nie zamarza.");
    }
    else
    {
        Console.WriteLine("Temperatura poniżej zera.");
    }
}
else
{
    Console.WriteLine("Niepoprawny format liczby.");
}

Struktura jest zawsze podobna:

if (warunek)
{
    // blok wykonywany, gdy warunek == true
}
else
{
    // blok wykonywany, gdy warunek == false
}

Blok else nie jest obowiązkowy – przy prostych sprawdzeniach nie zawsze ma sens:

if (wiek < 0)
{
    Console.WriteLine("Wiek nie może być ujemny.");
}

else if – kilka wariantów zamiast zagnieżdżania

Przy kilku możliwych ścieżkach można zagnieżdżać if w else, ale szybciej robi się czytelny łańcuch else if:

Console.Write("Podaj wynik testu (0-100): ");
string? tekst = Console.ReadLine();

if (!int.TryParse(tekst, out int wynik))
{
    Console.WriteLine("To nie jest poprawna liczba.");
}
else if (wynik < 0 || wynik > 100)
{
    Console.WriteLine("Wynik musi być między 0 a 100.");
}
else if (wynik >= 90)
{
    Console.WriteLine("Ocena: 5");
}
else if (wynik >= 75)
{
    Console.WriteLine("Ocena: 4");
}
else if (wynik >= 50)
{
    Console.WriteLine("Ocena: 3");
}
else
{
    Console.WriteLine("Ocena: 2");
}

To już całkiem typowy scenariusz: walidacja wejścia, a potem różne ścieżki w zależności od zakresu wartości.

Porównania – operatory relacyjne

Warunki w if zwykle opierają się na operatorach porównania:

• == – równe,
• != – różne,
• >, >=, <, <= – większe, mniejsze itd.

Przykład prostego logowania:

const string PrawidloweHaslo = "tajne";

Console.Write("Podaj hasło: ");
string? haslo = Console.ReadLine();

if (haslo == PrawidloweHaslo)
{
    Console.WriteLine("Dostęp przyznany.");
}
else
{
    Console.WriteLine("Błędne hasło.");
}

Przy łańcuchach znaków sprawa porównań bywa bardziej śliska (wielkość liter, kultura, lokalizacja), ale na poziomie pierwszych ćwiczeń operator == zwykle wystarcza. W bardziej wymagających scenariuszach w grę wchodzi string.Equals z dodatkowymi parametrami.

Logika złożona – łączenie warunków operatorem AND/OR

Kiedy jeden warunek to za mało, wchodzi w grę kombinacja:

Console.Write("Podaj wiek: ");
int.TryParse(Console.ReadLine(), out int wiek);

Console.Write("Czy masz prawo jazdy? (t/n): ");
string? odp = Console.ReadLine();

bool maPrawko = odp == "t" || odp == "T";

if (wiek >= 18 && maPrawko)
{
    Console.WriteLine("Możesz wypożyczyć samochód.");
}
else
{
    Console.WriteLine("Nie spełniasz warunków wypożyczenia.");
}

&& i || w C# są „leniwe” – jeśli wynik da się ustalić na podstawie pierwszego członu, drugi nie jest w ogóle sprawdzany. Czasem to po prostu detal wydajnościowy, a czasem ważna właściwość, np. gdy drugi warunek zakłada, że pierwszy już się spełnia (np. dostęp do kolekcji pod indeksem).

switch – czytelna alternatywa dla wielu if

Dla kilku prostych przypadków if wystarcza. Gdy warunek zależy od tej samej zmiennej i wybór jest z góry określony, switch bywa czytelniejszy:

Console.Write("Wybierz opcję (1-3): ");
string? tekst = Console.ReadLine();

if (!int.TryParse(tekst, out int opcja))
{
    Console.WriteLine("Niepoprawna opcja.");
    return;
}

switch (opcja)
{
    case 1:
        Console.WriteLine("Wybrano: dodawanie.");
        break;
    case 2:
        Console.WriteLine("Wybrano: odejmowanie.");
        break;
    case 3:
        Console.WriteLine("Wybrano: mnożenie.");
        break;
    default:
        Console.WriteLine("Nieznana opcja.");
        break;
}

break kończy obsługę danego przypadku. Bez break wykonanie „przeleci” do kolejnego case’a (tzw. fall-through), co rzadko jest pożądane – kompilator zresztą w wielu sytuacjach to blokuje.

switch expression – zwracanie wartości na podstawie wariantu

Nowsze wersje C# wprowadzają switch expression – zamiast wielu linii z Console.WriteLine można zwrócić jedną wartość w zależności od przypadku:

Console.Write("Podaj dzień tygodnia (1-7): ");
int.TryParse(Console.ReadLine(), out int dzien);

string nazwa = dzien switch
{
    1 => "Poniedziałek",
    2 => "Wtorek",
    3 => "Środa",
    4 => "Czwartek",
    5 => "Piątek",
    6 => "Sobota",
    7 => "Niedziela",
    _ => "Nieznany dzień"
};

Console.WriteLine(nazwa);

Podkreślenie (_) działa jako „wszystko inne”, odpowiednik default. Taka forma jest wygodna, gdy wynik przechowujesz w zmiennej, a nie tylko „wypisujesz i zapominasz”.

while – pętla z warunkiem na początku

Pętla while służy do powtarzania bloku kodu, dopóki warunek pozostaje prawdziwy:

int licznik = 0;

while (licznik < 5)
{
    Console.WriteLine($"Iteracja {licznik}");
    licznik++; // zwiększamy, żeby pętla kiedyś się skończyła
}

Typowy scenariusz w aplikacji konsolowej – wielokrotnie pytamy użytkownika, aż wpisze poprawną wartość:

int wiek;

while (true)
{
    Console.Write("Podaj swój wiek: ");
    string? tekst = Console.ReadLine();

    if (int.TryParse(tekst, out wiek) && wiek >= 0)
    {
        break; // wychodzimy z pętli
    }

    Console.WriteLine("Wpisz nieujemną liczbę całkowitą.");
}

Console.WriteLine($"Twój wiek: {wiek}.");

Warunek while (true) tworzy pętlę nieskończoną, z której wychodzi się ręcznie przez break. To wygodny, ale też łatwy do nadużycia wzorzec – drobna pomyłka i otrzymasz program, który „nigdy” się nie kończy.

do…while – przynajmniej jedno wykonanie

W while warunek sprawdzany jest przed wejściem do pętli. Czasem jednak blok kodu ma się wykonać co najmniej raz, a dopiero potem chcesz zdecydować, czy kontynuować. Do tego służy do...while:

string? odpowiedz;

do
{
    Console.Write("Czy chcesz kontynuować? (t/n): ");
    odpowiedz = Console.ReadLine();
}
while (odpowiedz != "n" && odpowiedz != "N");

Console.WriteLine("Koniec programu.");

Najpierw następuje wykonanie bloku po do, dopiero potem sprawdzenie warunku. Gdyby ten sam kod napisać na while, trzeba by zduplikować fragment lub dodać dodatkową zmienną sterującą.

for – licznikowa pętla po znanej liczbie kroków

Jeśli wiesz, ile powtórzeń ma być z góry, wygodniejszy bywa for:

for (int i = 0; i < 5; i++)
{
    Console.WriteLine($"i = {i}");
}

Składnia ma trzy elementy rozdzielone średnikami:

• inicjalizacja (np. int i = 0),
• warunek kontynuacji (i < 5),
• operacja wykonywana po każdym przebiegu (i++).

W praktyce na początku najczęściej spotyka się pętle typu „wypisz 10 razy komunikat” albo „policz sumę 1..N”:

Najczęściej zadawane pytania (FAQ)

Od czego najlepiej zacząć naukę C# – od konsoli, WinForms, WPF czy od razu od ASP.NET/Unity?

Bezpiecznym punktem startu są małe aplikacje konsolowe. Pozwalają skupić się wyłącznie na logice programu: zmiennych, instrukcjach warunkowych, pętlach, metodach. Nie trzeba jednocześnie ogarniać HTML-a, silnika Unity ani rozbudowanego interfejsu graficznego.

WinForms, WPF, ASP.NET czy Unity mają dodatkowe warstwy z własnymi zasadami. Wejście w nie „na dzień dobry” zwykle kończy się frustracją, bo trudno odróżnić, co jest problemem w samym C#, a co w wybranej technologii. Po kilkunastu–kilkudziesięciu małych projektach konsolowych przejście do weba lub gier jest znacznie mniej bolesne.

Jakie narzędzia są potrzebne, żeby zacząć programować w C# za darmo?

Do startu wystarczy .NET SDK, darmowy edytor lub IDE oraz terminal. Typowy zestaw to:

• .NET SDK (oficjalny pakiet z kompilatorem i narzędziami wiersza poleceń),
• Visual Studio Community na Windows lub VS Code na Windows/macOS/Linux,
• wbudowany terminal: PowerShell, cmd albo terminal w systemie Unixowym.

Dodatkowe płatne narzędzia, pluginy czy chmura nie są na początku konieczne. Najczęściej szybciej nauczysz się C#, używając prostego, darmowego zestawu, niż konfigurując rozbudowane środowisko, którego i tak nie wykorzystasz w 10%.

Jak sprawdzić, czy C# i .NET są poprawnie zainstalowane?

Po instalacji .NET SDK otwórz nowy terminal i wpisz polecenie:
dotnet --version. Jeśli zobaczysz numer wersji (np. 8.x.x), środowisko jest skonfigurowane prawidłowo. Brak rozpoznania komendy zwykle oznacza problem z instalacją albo z konfiguracją zmiennej PATH.

Najpierw wyklucz proste przyczyny: terminal otwarty przed instalacją, brak restartu systemu po instalacji, pomylenie SDK z samym runtime’em. Dopiero później ma sens grzebać głębiej w ustawieniach systemu czy ręcznie poprawiać PATH.

Jak stworzyć pierwszy projekt konsolowy w C# z linii komend?

Minimalny scenariusz wygląda tak: wybierz folder roboczy (np. C:ProjektyCSharp), otwórz w nim terminal, a następnie wykonaj:

• dotnet new console -n MojaPierwszaAplikacja – generuje projekt konsolowy,
• cd MojaPierwszaAplikacja – przejście do katalogu projektu,
• dotnet run – kompilacja i uruchomienie programu.

Jeśli ten proces działa od początku do końca, masz działające środowisko dla C#. Problemy na którymkolwiek etapie (brak szablonów, błędy kompilacji przykładowego kodu) sygnalizują kłopot z instalacją, a nie z Twoim programowaniem.

C# vs C i C++ – czym się faktycznie różnią na starcie?

Największa różnica dla początkującego to poziom abstrakcji i zarządzanie pamięcią. C i C++ wymagają ręcznej troski o pamięć (alokacja, zwalnianie, wycieki). C# działa na środowisku .NET z garbage collectorem, który przejmuje większość niskopoziomowych obowiązków. Dzięki temu możesz dłużej ignorować szczegóły działania pamięci i skupić się na algorytmach.

Podobieństwo nazw bywa mylące – to nie są „kolejne poziomy tego samego języka”. Część koncepcji się pokrywa (pętle, funkcje/metody), ale sposób pracy, ekosystem i narzędzia są inne. Przeskok z C# do C++ lub odwrotnie jest możliwy, jednak nie jest to automatyczny „upgrade”.

Czy muszę rozumieć CLR, JIT, GC, typy referencyjne i wartościowe na samym początku?

Na pierwsze tygodnie wystarczy ogólna świadomość, co te skróty oznaczają – bez zagłębiania się w szczegóły. Przykładowo: CLR to środowisko, które uruchamia kod C#, JIT kompiluje go „w locie”, a GC sprząta nieużywaną pamięć. Szczegółowa wiedza o ich działaniu przydaje się głównie później, przy optymalizacji i debugowaniu trudniejszych błędów.

Znacznie bardziej palące na starcie są umiejętności typowo „ręczne”: pisanie prostych algorytmów krok po kroku, czytanie komunikatów kompilatora, rozumienie przepływu programu w pętli. Zwykle dopiero po serii małych projektów pytania o CLR czy GC zaczynają mieć realny sens.

Co realnie da się zrobić w samej konsoli i czy to nie jest strata czasu?

Na konsoli da się zbudować więcej, niż się wydaje: kalkulatory, proste organizery z zapisem do pliku, konwertery danych, automaty do przetwarzania plików, małe gry tekstowe. W wielu firmach nadal używa się narzędzi konsolowych do automatyzacji zadań administracyjnych czy integracji.

Dla osoby uczącej się C# konsola działa jak „rentgen” kodu – każdy błąd logiki widać natychmiast w wynikach wypisywanych na ekran. W aplikacjach webowych czy grach trudno rozdzielić, co nie działa przez kod, a co przez konfigurację serwera, przeglądarkę, zasoby gry lub UI. Z tej perspektywy praca w konsoli to raczej przyspieszenie nauki niż cofanie się do „przestarzałych” narzędzi.