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

camelCase a PascalCase: jaka jest różnica?

Jedyna różnica między camelCase a PascalCase to pierwsza litera. camelCase zaczyna się małą literą, a każdy kolejny wyraz zaczyna wielką literą (userName, parseResponse). PascalCase pisze wielką literą każdy wyraz, także pierwszy (UserName, ResponseParser). Zgodnie z konwencją PascalCase oznacza typy (klasy, interfejsy, wyliczenia, komponenty Reacta), a camelCase wartości i czynności (zmienne, funkcje, metody, właściwości).

Ta jedna wielka litera niesie więcej informacji, niż się wydaje. Poniżej: co sygnalizuje, w jakich językach jest wymuszana, a nie tylko zalecana, oraz część, co do której nikt nie jest zgodny, czyli skróty.

camelCase i PascalCase w skrócie

Uważaj na słownictwo, gdy czytasz przewodniki stylu. Wiele osób mówi „camel case” o obu stylach, a PEP 8 wymienia nawet CamelCase jako inną nazwę CapWords, swojego terminu na PascalCase. Jeśli sens przewodnika nie jest oczywisty, spójrz na jego przykłady.

Dlaczego pierwsza litera ma znaczenie: typy i wartości

Dzięki tej konwencji czytasz kod, niczego nie sprawdzając. W const invoice = new Invoice(order) od razu widać, że Invoice jest tym, co konstruujesz, a invoice tym, co otrzymujesz z powrotem. Sygnatury w TypeScripcie działają tak samo: w function total(order: Order): Money nazwa pisana małą literą to wartość, a nazwy pisane wielką to typy.

Pozwala też, by jedno słowo nazywało zarówno typ, jak i wartość bez kolizji, co zdarza się nieustannie: user: User, config: Config, request: Request. W języku rozróżniającym wielkość liter to różne identyfikatory, a wielka litera mówi czytelnikowi, który jest który.

Gdzie wymusza to język

W JavaScripcie, Javie, C# i Pythonie wielkość liter w nazwie klasy to tylko konwencja. Nic nie stoi na przeszkodzie, by napisać class invoice. W JavaScripcie konwencję można zamienić w kontrolę regułą new-cap z ESLint: domyślnie zgłasza ona new invoice(), a także wywołanie funkcji pisanej wielką literą, takiej jak Invoice(), bez new, co zwykle jest błędem. Kilka języków i frameworków idzie dalej i wbudowuje tę regułę.

Go: pierwsza litera to reguła widoczności

Go nie ma słów kluczowych public ani private. Nazwa na poziomie pakietu, pole struktury lub metoda jest eksportowana, jeśli jej pierwsza litera jest wielka, a prywatna dla swojego pakietu, jeśli jest mała. O wyborze decyduje więc PascalCase albo camelCase.

package shapes

import "math"

// Circle is exported, so other packages can use it.
type Circle struct {
	Radius float64 // exported field
	label  string  // unexported field
}

// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }

// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }

c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c))   // fine
fmt.Println(shapes.square(2)) // compile error: square is not exported

Dlatego też Effective Go mówi, że getter niewyeksportowanego pola owner powinien nazywać się Owner, a nie GetOwner. Wielka litera sama już mówi, że to publiczna droga dostępu.

React: komponenty muszą zaczynać się wielką literą

Dokumentacja Reacta jest w tej sprawie stanowcza: nazwy komponentów muszą zaczynać się wielką literą, inaczej nie zadziałają. JSX traktuje tag pisany małą literą, taki jak <section>, jako element HTML, a pisany wielką, taki jak <OrderSummary />, jako Twój komponent.

Ruby: nazwy klas są stałymi

W Ruby każda nazwa zaczynająca się wielką literą jest stałą, a nazwy klas muszą być stałymi. class Invoice działa; class invoice to błąd składni („class/module name must be CONSTANT”, czyli nazwa klasy lub modułu musi być stałą).

Który styl wybrać, język po języku

• JavaScript i TypeScript: camelCase dla zmiennych, funkcji, metod i właściwości; PascalCase dla klas, interfejsów, aliasów typów, wyliczeń i komponentów.
• Java i Kotlin: ten sam podział, a dla prawdziwych stałych wielkie litery z podkreślnikami (MAX_RETRIES).
• C#: PascalCase jest tu znacznie częstszy niż w innych językach. Metody, właściwości, zdarzenia, pola publiczne, przestrzenie nazw, a nawet stałe piszemy w PascalCase; camelCase jest dla parametrów i zmiennych lokalnych, a _camelCase dla pól prywatnych. Typowa sygnatura wygląda tak: public decimal CalculateTotal(decimal taxRate).
• Swift: PascalCase dla typów i protokołów, camelCase dla wszystkiego innego.
• Go: ten, który pasuje do widoczności, jakiej chcesz.
• Python: PascalCase tylko dla klas. Funkcje i zmienne to snake_case, a PEP 8 dopuszcza camelCase tylko tam, gdzie jest już dominującym stylem w starszym kodzie.
• PHP (PSR-1): klasy w PascalCase, metody w camelCase.

O stałych, plikach i całej reszcie przeczytasz w naszej ściągawce ze stylami nazewnictwa dla programistów.

Najtrudniejsza część: skróty i skrótowce

userId czy userID? HttpClient czy HTTPClient? Główne przewodniki stylu dają różne odpowiedzi:

Nasza rada: jeśli przewodnik Twojego języka ma regułę, trzymaj się jej, bo tego oczekują biblioteka standardowa i Twoi współpracownicy. Jeśli nie ma, traktuj skróty jak wyrazy (HttpClient, userId). Granice wyrazów pozostają widoczne, gdy spotykają się dwa skróty (porównaj XMLHTTPRequest z XmlHttpRequest), a nazwy przetrwają automatyczną konwersję między stylami. Nawet przeglądarkowy XMLHttpRequest miesza oba podejścia w jednej nazwie.

Dla szerszego kontekstu: konwencje wielkich liter Microsoftu to dobry przykład kompletnego zestawu reguł spisanego na jednej stronie.

Konwersja między camelCase a PascalCase

Dla prostej nazwy konwersja to jeden znak: zmień wielkość pierwszej litery.

const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);

toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal");  // "orderTotal"
toCamel("HTMLParser");  // "hTMLParser" (acronyms need a smarter split)

Ostatnia linijka to powód, dla którego narzędzia najpierw dzielą nazwy na wyrazy. Oto, co konwerter wielkości liter ConvertCaseHQ daje dla kilku kłopotliwych danych wejściowych:

Dzieli nazwy na istniejących wielkich literach i zapisuje skróty jak wyrazy, co zgadza się z regułą Google. Jeśli Twój projekt stosuje reguły dotyczące skrótów z Go, .NET lub PEP 8, popraw te nazwy ręcznie (w Go getUserId staje się getUserID). Drugą pułapką są nazwy marek: żaden algorytm nie wie, że IPhone wygląda źle.

Dwa łatwe potknięcia

Pierwsze to pisanie instancji wielką literą: const Cart = new ShoppingCart() sprawia, że Cart wygląda jak druga klasa, a kolejny czytelnik pójdzie szukać jej definicji. Drugie to pomocnicza funkcja w PascalCase w JavaScripcie, taka jak function FormatPrice(). Jeśli to nie konstruktor ani komponent Reacta, czytelnicy założą, że potrzebuje new albo JSX, a new-cap będzie narzekać, gdy wywołasz ją bez żadnego z nich.

Praktyczna reguła

Jeśli to typ albo coś, co konstruujesz przez new, użyj PascalCase. Jeśli to wartość lub czynność, użyj camelCase. Skróty niech rozstrzyga przewodnik Twojego języka, a resztę niech zapamięta linter. Szczegóły dotyczące JavaScriptu, w tym stałe i pola prywatne, znajdziesz w naszym poradniku o nazewnictwie w JavaScripcie.