← Blog · 19 kwietnia 2026 · Zespół ConvertCaseHQ · 6 min czytania

camelCase, snake_case, kebab-case: ściągawka z konwencji nazewnictwa

Oto wersja skrócona. Typy i klasy dostają PascalCase w niemal każdym języku. Zmienne i funkcje dostają camelCase w JavaScripcie, Javie, C#, Kotlinie i Swifcie, ale snake_case w Pythonie, Ruby i Rust. Stałe dostają SCREAMING_SNAKE_CASE w większości języków; wyjątki to Go, Swift, C# i C++ w stylu Google. Wszystko, co trafia do adresu URL, pliku CSS albo nazwy pakietu, to zwykle kebab-case małymi literami, a zmienne środowiskowe piszemy wielkimi literami z podkreślnikami.

To jest wzorzec. O szczegóły toczą się spory podczas code review, dlatego ta ściągawka trzyma się tego, co faktycznie mówi oficjalny lub najczęściej używany przewodnik stylu danego języka, i wskazuje źródło dla każdego z nich.

camelCase, snake_case, kebab-case: pięć stylów i ich inne nazwy

• camelCase (orderTotal): pierwszy wyraz małymi literami, każdy kolejny od wielkiej. Nazywany też lowerCamelCase; PEP 8 nazywa go mixedCase.
• PascalCase (OrderTotal): każdy wyraz od wielkiej litery. Znany też jako UpperCamelCase, CapWords (PEP 8) albo StudlyCaps (PSR-1 w PHP).
• snake_case (order_total): wyrazy małymi literami połączone podkreślnikami.
• SCREAMING_SNAKE_CASE (ORDER_TOTAL): wyrazy wielkimi literami połączone podkreślnikami. Przewodnik Google do JavaScriptu nazywa go CONSTANT_CASE, a przewodnik do Javy UPPER_SNAKE_CASE.
• kebab-case (order-total): wyrazy małymi literami połączone łącznikami. W większości języków nie da się go użyć w identyfikatorach, bo łącznik to znak minus.

Aby zamienić nazwę z jednego stylu na drugi, wklej ją do naszego konwertera wielkości liter. Dzieli tekst na spacjach, podkreślnikach, łącznikach i istniejących wielkich literach, więc order_total, order-total i OrderTotal bez problemu zamieniają się jedno w drugie. Rób to jednak po jednej nazwie: konwerter traktuje wszystko w polu jako jeden identyfikator.

Ściągawka: konwencje nazewnictwa według języka

Kilka wierszy wymaga przypisu. W Go pierwsza litera w ogóle nie jest kwestią stylu: to reguła widoczności. Area jest eksportowane z pakietu, a area nie, i pilnuje tego kompilator. C++ nie ma konwencji obowiązującej w całym języku; sama biblioteka standardowa używa snake_case (std::unordered_map, push_back), więc wiersz Google traktuj jako jedną dobrze udokumentowaną opcję, a nie regułę.

Rust jest wyjątkowo rygorystyczny w kwestii stylu. Kompilator ostrzega bez żadnej konfiguracji: napisz fn GetUser() albo struct user_account, a rustc podpowie get_user i UserAccount, zanim uruchomisz lintera.

Nazwy plików, modułów i pakietów

• Java: publiczna klasa najwyższego poziomu musi leżeć w pliku o dokładnie takiej samej nazwie, łącznie z wielkimi literami. OrderService trafia do OrderService.java, a javac odrzuci każdą inną nazwę.
• Kotlin: plik z jedną klasą nazywa się tak jak ta klasa. Pozostałe pliki dostają opisową nazwę w UpperCamelCase, na przykład ProcessDeclarations.kt.
• Python: moduły dostają krótkie nazwy zapisane samymi małymi literami, z podkreślnikami, jeśli poprawiają czytelność. Pakiety też powinny być krótkie i pisane małymi literami, a PEP 8 odradza w nich podkreślniki.
• Ruby: pliki w snake_case, nazwane tak jak klasa w środku, więc HelloWorld leży w hello_world.rb.
• Go: nazwy pakietów to pojedyncze wyrazy pisane małymi literami, bez podkreślników i mixedCaps: base64, a nie encoding_base64 ani encodingBase64.
• JavaScript i TypeScript: brak jednej reguły. Przewodnik Google do JavaScriptu chce nazw plików samymi małymi literami, z podkreślnikami lub łącznikami, a jego przewodnik do TypeScriptu używa snake_case. Przewodnik Airbnb mówi, że nazwa pliku powinna odpowiadać jego eksportowi domyślnemu, więc klasa CheckBox leży w CheckBox.js. Wybierz jedną regułę na projekt i ją zapisz.
• Pakiety npm: nowe nazwy pakietów w ogóle nie mogą zawierać wielkich liter.

Poza kodem źródłowym: zmienne środowiskowe, CSS, HTML, adresy URL, JSON i SQL

Jedna osobliwość zmiennych środowiskowych: POSIX mówi, że standardowe narzędzia używają nazw pisanych wielkimi literami, a nazwy zawierające małe litery rezerwuje dla aplikacji, więc nazwa małymi literami nigdy nie zderzy się ze standardową. Wielkie litery pozostają jednak ugruntowanym nawykiem, więc my zostalibyśmy przy nich, a żeby uniknąć kolizji, dodalibyśmy charakterystyczny prefiks (MYAPP_TIMEOUT).

Wiersze o CSS i SQL mają własne wpisy: o nazwach klas przeczytasz w wpisie o nazewnictwie w CSS i BEM, a o tym, dlaczego bazy danych popychają Cię ku małym literom, w wpisie o konwencjach nazewnictwa w SQL.

Skróty: tu przewodniki stylu się rozchodzą

Wszystkie przewodniki zgadzają się co do userName. Rozchodzą się przy userID. Przewodniki Google do JavaScriptu i Javy zapisują skróty jak zwykłe wyrazy (xmlHttpRequest, customerId). Go zachowuje każdy skrót w jednej wielkości liter (ServeHTTP, appID). Wytyczne Microsoftu dla .NET zapisują wielkimi literami obie litery skrótu dwuliterowego (IOStream), ale tylko pierwszą literę skrótów dłuższych (HtmlTag). Rust traktuje je jak wyrazy (Uuid), a PEP 8 woli HTTPServerError od HttpServerError. Porównujemy te opcje obok siebie we wpisie camelCase a PascalCase.

Jak wybrać, gdy nie masz pewności

1. Sprawdź, czy decyduje za Ciebie platforma. Nazwy właściwości CSS, nazwy plików w Javie, eksportowane nazwy w Go i nazwy komponentów Reacta (które muszą zaczynać się wielką literą) to nie są wybory stylistyczne.
2. Trzymaj się oficjalnego przewodnika języka. Nowy kod powinien wyglądać jak biblioteka standardowa, obok której stoi.
3. Dopasuj się do istniejącego projektu. PEP 8 mówi to wprost: spójność w obrębie projektu jest ważniejsza niż spójność z przewodnikiem stylu.
4. Niech zapamięta to linter. Reguła camelcase w ESLint, reguły N w Ruff dla Pythona i wbudowane ostrzeżenia rustc wyłapią potknięcia, zanim zrobi to recenzent.
5. Konwertuj raz, na granicy. Gdy JSON w snake_case spotyka JavaScript w camelCase, zmień nazwy kluczy w jednej warstwie serializacji, zamiast pozwalać, by oba style przeciekały przez cały kod.