Nazwy są wszędzie. Nazywamy zmienne, funkcje, komponenty, klasy, pliki, foldery, kolumny w bazie danych, endpointy API, klasy CSS, zmienne środowiskowe i klucze konfiguracyjne. Na początku projektu może się wydawać, że to drobiazg. Przecież ważniejsze jest to, żeby kod działał.

Problem zaczyna się później.

Projekt rośnie, pojawia się więcej plików, więcej funkcji i więcej osób w zespole. Jedna osoba zapisuje nazwę jako userProfile, druga jako user_profile, trzecia jako UserProfile, a czwarta tworzy plik user-profile.tsx. Każdy z tych zapisów może być poprawny, ale nie każdy pasuje do tego samego miejsca.

Właśnie dlatego istnieją konwencje nazewnictwa. Pomagają utrzymać porządek i sprawiają, że już po samej nazwie łatwiej zrozumieć, z czym mamy do czynienia.

Przykładową frazę:

user profile name

można zapisać na wiele sposobów:

userProfileName
UserProfileName
user-profile-name
user_profile_name
USER_PROFILE_NAME
User-Profile-Name
user.profile.name

Każdy z tych zapisów wygląda inaczej i każdy ma swoje typowe zastosowanie.

---

Dlaczego konwencje nazewnictwa mają znaczenie?

Dobre nazewnictwo nie jest tylko kwestią estetyki. To część czytelności kodu.

Kiedy widzisz nazwę UserProfileCard, możesz się domyślić, że prawdopodobnie chodzi o komponent, klasę albo większą strukturę. Kiedy widzisz userProfileCard, wygląda to raczej jak zmienna lub funkcja. Z kolei USER_PROFILE_CARD od razu sugeruje stałą wartość.

To właśnie jest największa zaleta konwencji nazewnictwa: nazwa niesie dodatkową informację.

Spójne nazwy pomagają szybciej czytać kod, łatwiej odnajdywać pliki, lepiej rozumieć strukturę projektu i unikać niepotrzebnych decyzji. Nie trzeba za każdym razem zastanawiać się, czy nazwę pliku zapisać jako UserProfilePage, userProfilePage, user-profile-page czy user_profile_page. Projekt powinien mieć swoje zasady.

Najważniejsza reguła brzmi: styl nazewnictwa powinien pasować do miejsca, w którym jest używany.

---

camelCase

camelCase to jeden z najpopularniejszych stylów nazewnictwa w programowaniu. Polega na tym, że pierwsze słowo zaczyna się małą literą, a każde kolejne wielką.

Przykłady:

userName
userProfile
getUserProfile
isUserLoggedIn

Nazwa „camelCase” pochodzi od skojarzenia z garbami wielbłąda. Wielkie litery w środku nazwy tworzą charakterystyczne „wzniesienia”.

Ten styl jest bardzo popularny w JavaScript, TypeScript, Javie, Kotlinie czy C#. Najczęściej stosuje się go do nazw zmiennych, funkcji, metod, parametrów i właściwości obiektów.

Przykład:

const userName = "Anna";
const userProfileImage = "/images/avatar.png";function getUserProfile() {
  return {
    name: userName,
    image: userProfileImage
  };
}

W takim kodzie camelCase wygląda naturalnie. userName jest zmienną, getUserProfile jest funkcją, a userProfileImage opisuje konkretną wartość.

camelCase dobrze sprawdza się tam, gdzie nazwa jest częścią logiki programu. Jest czytelny, zwięzły i nie wymaga żadnych separatorów. Dzięki wielkim literom łatwo rozpoznać granice między słowami.

Nie jest to jednak najlepszy wybór dla wszystkiego. W adresach URL, nazwach plików czy klasach CSS częściej lepiej sprawdzi się kebab-case.

Zamiast:

userProfilePage.html

często lepiej użyć:

user-profile-page.html

---

PascalCase

PascalCase jest podobny do camelCase, ale z jedną ważną różnicą: pierwsze słowo również zaczyna się wielką literą.

Przykłady:

UserProfile
UserProfileCard
PaymentService
OrderHistoryPage

Ten styl jest często używany do nazw rzeczy, które reprezentują większe struktury w kodzie. Mogą to być klasy, komponenty, typy, interfejsy, enumy, modele danych albo konstruktory.

Przykład:

class UserAccount {
  constructor(public userName: string) {}
}type UserProfile = {
  id: number;
  name: string;
};function UserProfileCard() {
  return <div>User profile</div>;
}

W tym przykładzie UserAccount, UserProfile i UserProfileCard zapisane są w PascalCase, ponieważ nie są zwykłymi zmiennymi. Reprezentują pewien byt, strukturę albo komponent.

PascalCase jest szczególnie ważny w React. Komponenty Reacta powinny zaczynać się wielką literą, ponieważ dzięki temu React odróżnia je od zwykłych elementów HTML.

Poprawnie:

function UserProfileCard() {
  return <div>Profile</div>;
}

Mniej poprawnie jako komponent:

function userProfileCard() {
  return <div>Profile</div>;
}

PascalCase dobrze komunikuje: „to jest coś większego niż zwykła wartość”. Dlatego świetnie nadaje się do komponentów, klas i typów.

Nie warto go jednak używać do zwykłych zmiennych lokalnych.

Zamiast:

const UserName = "Anna";

lepiej napisać:

const userName = "Anna";

---

kebab-case

kebab-case to styl, w którym wszystkie litery są małe, a słowa oddzielone są myślnikami.

Przykłady:

user-profile
user-profile-name
main-navigation
blog-post-card

Jest to jeden z najczęściej spotykanych stylów w świecie web developmentu. Bardzo dobrze sprawdza się w URL-ach, slugach, nazwach plików, klasach CSS i endpointach.

Przykład adresu URL:

/blog/jak-nazywac-zmienne-w-kodzie

Przykład nazwy pliku:

user-profile-page.html

Przykład klasy CSS:

.user-profile-card {
  padding: 16px;
}

kebab-case jest czytelny dla ludzi i dobrze wygląda w adresach internetowych. Myślniki naturalnie oddzielają słowa, więc nawet dłuższy adres pozostaje zrozumiały.

Porównaj:

/blog/style-nazewnictwa-w-programowaniu

z:

/blog/styleNazewnictwaWProgramowaniu

Pierwszy zapis wygląda znacznie bardziej naturalnie jako URL.

Trzeba jednak pamiętać, że kebab-case nie nadaje się do nazw zmiennych w wielu językach programowania. W JavaScript myślnik oznacza odejmowanie, więc taki zapis będzie błędny:

const user-profile = "Anna";

Dlatego kebab-case najlepiej zostawić dla plików, URL-i, CSS-a i podobnych miejsc.

---

snake_case

snake_case używa małych liter i podkreślników między słowami.

Przykłady:

user_profile
user_profile_name
get_user_profile
is_user_logged_in

Ten styl jest szczególnie popularny w Pythonie, Ruby, SQL i bazach danych. W Pythonie jest standardowym wyborem dla zmiennych i funkcji.

Przykład:

user_name = "Anna"
user_profile_image = "avatar.png"def get_user_profile():
    return {
        "name": user_name,
        "image": user_profile_image
    }

W Pythonie taki zapis wygląda naturalnie i jest zgodny z oczekiwaniami większości programistów. Gdyby w tym samym kodzie pojawiło się getUserProfile, wyglądałoby to bardziej jak styl przeniesiony z JavaScriptu.

snake_case jest też bardzo częsty w bazach danych.

Przykład:

CREATE TABLE user_profiles (
  id INT,
  first_name VARCHAR(100),
  last_name VARCHAR(100),
  created_at TIMESTAMP
);

Nazwy takie jak first_name, last_name czy created_at są czytelne i dobrze działają w zapytaniach SQL.

W JavaScript i TypeScript snake_case zwykle nie jest domyślnym stylem dla zmiennych i funkcji. Można go spotkać, szczególnie gdy dane przychodzą z API lub bazy danych, ale w samym kodzie JS częściej używa się camelCase.

Przykład typowy dla JavaScriptu:

const userName = "Anna";function getUserProfile() {
  return {};
}

Przykład typowy dla Pythona:

user_name = "Anna"def get_user_profile():
    return {}

Oba style są dobre, ale w swoich środowiskach.

---

SCREAMING_SNAKE_CASE

SCREAMING_SNAKE_CASE wygląda jak snake_case, ale wszystkie litery są wielkie.

Przykłady:

MAX_USER_COUNT
API_BASE_URL
DEFAULT_LANGUAGE
ACCESS_TOKEN_SECRET

Ten styl jest najczęściej używany do stałych, zmiennych środowiskowych i wartości konfiguracyjnych. Wielkie litery od razu sugerują, że dana wartość ma specjalne znaczenie i raczej nie powinna być zmieniana w trakcie działania programu.

Przykład:

const MAX_RETRY_COUNT = 3;
const API_BASE_URL = "https://api.example.com";
const DEFAULT_LANGUAGE = "pl";

Przykład zmiennych środowiskowych:

DATABASE_URL=postgres://localhost:5432/app
API_KEY=123456
NODE_ENV=production

SCREAMING_SNAKE_CASE jest bardzo czytelny, ale też wizualnie „głośny”. Dlatego nie warto używać go wszędzie. Jeśli każda zmienna będzie zapisana wielkimi literami, przestanie to cokolwiek komunikować.

Niepotrzebnie:

const USER_NAME = "Anna";
const USER_EMAIL = "anna@example.com";

Lepiej:

const userName = "Anna";
const userEmail = "anna@example.com";

Wielkie litery warto zostawić dla wartości, które naprawdę są stałe albo konfiguracyjne.

---

Train-Case

Train-Case przypomina kebab-case, ale każde słowo zaczyna się wielką literą.

Przykłady:

User-Profile-Name
Content-Type
Accept-Language
Cache-Control

Ten styl jest mniej popularny jako ogólna konwencja w kodzie, ale można go spotkać w konkretnych kontekstach. Najbardziej znanym przykładem są nagłówki HTTP.

Przykład:

Content-Type: application/json
Accept-Language: pl-PL
Cache-Control: no-cache
User-Agent: Mozilla/5.0

Train-Case dobrze wygląda w nazwach technicznych, które mają charakter opisowy. Nie jest jednak stylem, który warto wybierać domyślnie do zmiennych, funkcji czy klas.

W JavaScript taki zapis byłby błędny jako nazwa zmiennej:

const User-Profile-Name = "Anna";

Tak samo jak przy kebab-case, myślnik zostałby potraktowany jak operator odejmowania.

---

dot.case

dot.case oddziela słowa kropkami.

Przykłady:

user.profile.name
app.theme.color
auth.login.error
settings.language.default

Ten styl jest dobry tam, gdzie nazwa ma strukturę hierarchiczną. Często spotkasz go w kluczach tłumaczeń, konfiguracjach, namespace’ach, nazwach metryk albo eventach analitycznych.

Przykład kluczy tłumaczeń:

{
  "auth.login.title": "Logowanie",
  "auth.login.error": "Nieprawidłowy login lub hasło",
  "user.profile.name": "Nazwa użytkownika"
}

Kropki pomagają pokazać relację między elementami. auth.login.error można czytać jako: obszar auth, ekran login, komunikat error.

dot.case nie nadaje się jednak jako zwykła nazwa zmiennej w wielu językach, bo kropka ma swoje znaczenie składniowe.

Niepoprawnie:

const user.profile.name = "Anna";

Poprawnie:

const user = {
  profile: {
    name: "Anna"
  }
};

---

path/case

path/case używa ukośników, czyli wygląda jak ścieżka.

Przykłady:

user/profile/name
src/components/user-profile
api/users/profile

Ten zapis jest naturalny dla folderów, plików, routingu i endpointów API. Nie jest to tak naprawdę styl nazewnictwa zmiennych, tylko sposób organizowania lokalizacji.

Przykład struktury projektu:

src/components/user-profile-card.tsx
src/pages/blog/article-page.tsx
api/users/profile

path/case pomaga porządkować projekt i pokazywać, gdzie coś się znajduje. W aplikacjach webowych często odpowiada też strukturze adresów URL.

---

Title Case i Sentence case

Nie wszystkie style nazewnictwa dotyczą kodu. Część z nich pojawia się bardziej w tekstach, nagłówkach i interfejsach.

Title Case oznacza, że każde ważne słowo zaczyna się wielką literą.

Przykład:

How to Name Variables in Programming

Ten styl często pojawia się w tytułach artykułów, dokumentów, prezentacji i nagłówków.

Sentence case wygląda bardziej jak zwykłe zdanie. Wielką literą zaczyna się tylko pierwsze słowo.

Przykład:

How to name variables in programming

Sentence case często dobrze sprawdza się w interfejsach użytkownika, komunikatach i przyciskach.

Przykłady:

Save changes
Create new account
Invalid email address
Password has been changed

W aplikacjach taki zapis bywa spokojniejszy i bardziej naturalny niż Title Case.

Porównaj:

Create New Account

z:

Create new account

Obie wersje są zrozumiałe, ale druga często brzmi bardziej jak element nowoczesnego interfejsu.

---

Jak wybrać odpowiedni styl?

Najprościej: nie zaczynaj od pytania „który styl mi się najbardziej podoba?”. Lepiej zapytać: gdzie ta nazwa będzie używana?

Innego stylu użyjesz dla zmiennej w JavaScript, innego dla komponentu React, innego dla kolumny w SQL, a jeszcze innego dla adresu URL.

W JavaScript i TypeScript najczęściej spotkasz taki podział:

camelCase — zmienne i funkcje
PascalCase — klasy, typy i komponenty
SCREAMING_SNAKE_CASE — stałe konfiguracyjne
kebab-case — pliki, foldery i URL-e

W Pythonie typowy zestaw wygląda inaczej:

snake_case — zmienne i funkcje
PascalCase — klasy
SCREAMING_SNAKE_CASE — stałe

W CSS naturalnym wyborem często będzie kebab-case:

.user-profile-card {
  display: flex;
}

W bazach danych bardzo często stosuje się snake_case:

created_at
user_id
first_name

A w URL-ach najlepiej zwykle wygląda kebab-case:

/blog/jak-stosowac-style-nazewnictwa

Nie chodzi więc o to, żeby jeden styl uznać za najlepszy. Każdy z nich jest dobry, jeśli używasz go w odpowiednim miejscu.

---

Krótka ściąga

Sytuacja	Najczęstszy styl	Przykład
Zmienna w JavaScript	camelCase	userName
Funkcja w JavaScript	camelCase	getUserProfile()
Klasa	PascalCase	UserProfile
Komponent React	PascalCase	UserProfileCard
Typ w TypeScript	PascalCase	UserProfile
Zmienna w Pythonie	snake_case	user_name
Funkcja w Pythonie	snake_case	get_user_profile()
Stała	SCREAMING_SNAKE_CASE	MAX_RETRY_COUNT
Zmienna środowiskowa	SCREAMING_SNAKE_CASE	DATABASE_URL
URL	kebab-case	/user-profile
Slug	kebab-case	jak-nazywac-zmienne
Klasa CSS	kebab-case	.user-profile-card
Kolumna w SQL	snake_case	created_at
Klucz tłumaczenia	dot.case	auth.login.error
Ścieżka pliku	path/case	src/components/button
Nagłówek HTTP	Train-Case	Content-Type
Tytuł artykułu	Title Case lub Sentence case	How to name variables

---

Najczęstszy błąd: mieszanie stylów

Największy problem pojawia się wtedy, gdy style są mieszane bez żadnej reguły.

Przykład:

const user_name = "Anna";
const userAge = 28;
const UserEmail = "anna@example.com";
const USER_profile_status = "active";

Technicznie część z tych nazw może działać, ale całość wygląda chaotycznie. Nie wiadomo, czy wielkie litery coś oznaczają, czy są przypadkowe. Nie wiadomo też, jaka konwencja obowiązuje w projekcie.

Lepsza wersja:

const userName = "Anna";
const userAge = 28;
const userEmail = "anna@example.com";
const userProfileStatus = "active";

Kod jest prostszy do przeczytania, bo wszystkie zmienne trzymają się tej samej zasady.

---

Konsekwencja jest ważniejsza niż perfekcja

W praktyce najważniejsza nie jest znajomość wszystkich możliwych stylów. Najważniejsza jest konsekwencja.

Dobry projekt powinien mieć jasne reguły. Na przykład:

Zmienne i funkcje: camelCase
Komponenty i klasy: PascalCase
Stałe: SCREAMING_SNAKE_CASE
Pliki i URL-e: kebab-case
Baza danych: snake_case

Takie zasady zdejmują z zespołu wiele małych decyzji. Nikt nie musi się zastanawiać, jak nazwać nowy komponent, jak zapisać nazwę pliku albo czy stała powinna być wielkimi literami. Wszystko wynika z konwencji.

To szczególnie ważne w większych projektach. Kod czyta się znacznie częściej, niż się go pisze. Dobre nazwy pomagają kolejnym osobom szybciej zrozumieć, co dzieje się w aplikacji.

---

Podsumowanie

Style nazewnictwa są małym detalem, który ma duży wpływ na czytelność projektu.

camelCase najlepiej sprawdza się przy zmiennych i funkcjach w JavaScript oraz TypeScript.

PascalCase jest dobrym wyborem dla klas, typów i komponentów.

kebab-case świetnie pasuje do URL-i, slugów, nazw plików i klas CSS.

snake_case jest standardem w Pythonie i bardzo częstym wyborem w bazach danych.

SCREAMING_SNAKE_CASE warto stosować dla stałych i zmiennych środowiskowych.

Train-Case pojawia się między innymi w nagłówkach HTTP.

dot.case dobrze działa w konfiguracjach, tłumaczeniach i nazwach hierarchicznych.

Nie ma jednego stylu, który pasuje wszędzie. Dobry wybór zależy od kontekstu: języka, frameworka, narzędzia i miejsca, w którym nazwa będzie używana.

Najlepsza zasada jest prosta: używaj stylu, który jest naturalny dla danej technologii, i trzymaj się go konsekwentnie.

Dobre nazwy nie tylko opisują kod. One pomagają go czytać, rozumieć i rozwijać.