← Blog · 16 kwietnia 2026 · Zespół ConvertCaseHQ · 7 min czytania

Nazewnictwo zmiennych w JavaScripcie: przewodnik po camelCase dla programistów

W JavaScripcie zmienne, funkcje, parametry i właściwości obiektów nazywaj w camelCase (cartTotal, fetchOrders), klasy i komponenty Reacta w PascalCase (ShoppingCart), a CONSTANT_CASE zachowaj dla wartości, które są stałe przez cały czas życia programu (MAX_RETRIES). Przewodniki stylu Google i Airbnb zgadzają się co do tego, a wbudowane elementy samego JavaScriptu stosują ten sam wzorzec.

Reszta przewodnika omawia najpierw to, co faktycznie wymusza silnik, potem konwencje nałożone na wierzch, a na końcu przypadki brzegowe, w których zespoły się nie zgadzają: które wartości const zasługują na wielkie litery, pola prywatne, skróty i dane w snake_case przychodzące z API.

Co dopuszcza sam JavaScript

Reguły języka są krótkie. Identyfikator zaczyna się od litery, podkreślnika lub znaku dolara, a dalsze znaki mogą być też cyframi. Litery nie ograniczają się do ASCII: przykład z samego MDN to niemieckie słowo Früh. Nazwy rozróżniają wielkość liter, więc total i Total to dwie różne zmienne, a słów zastrzeżonych, takich jak new, class i delete, nie można używać jako nazw zmiennych.

let total = 1;
let Total = 2;      // a different variable
const café = "ok";  // Unicode letters are allowed
const $price = 9.99;
const _unused = null;

// const 2fast = true;  // SyntaxError: can't start with a digit
// const new = 1;       // SyntaxError: reserved word

Nazwy właściwości są jeszcze luźniejsze: zadziała dowolny ciąg znaków, jeśli ujmiesz go w cudzysłów, dzięki czemu możliwe jest headers["Content-Type"]. Wszystko poza tymi regułami to konwencja i właśnie dlatego warto się co do niej umówić.

camelCase dla zmiennych, funkcji i właściwości

camelCase to domyślny styl prawie wszystkiego, co nazywasz w JavaScripcie. Wartościom nadawaj nazwy rzeczownikowe, a funkcjom czasownikowe, żeby wiersz czytał się jak zdanie:

const orderCount = orders.length;
const isLoggedIn = Boolean(session);
const user = { firstName: "Ada", lastLogin: null };

function calculateShipping(order) {
  // ...
}

Dla wartości logicznych prefiks is, has lub can (isLoggedIn, hasAccess) odpowiada na pytanie „prawda lub fałsz czego?”, zanim ktokolwiek je zada. Przewodnik Google używa tych samych prefiksów dla getterów logicznych (isFoo, hasFoo).

Przewodnik Google ma też dobrą regułę dotyczącą długości: bądź tak opisowy, jak rozsądnie się da, i nie skracaj przez usuwanie liter. errorCount i customerId przechodzą; nErr i cstmrId nie. Wyjątkiem w przewodniku jest zmienna widoczna w zakresie dziesięciu wierszy lub mniej, taka jak i w krótkiej pętli albo x w points.map((x) => x * 2).

Kolekcje, liczniki i procedury obsługi zdarzeń

Kilka wzorców sprawia, że nazwy są przewidywalne. Dla tablicy użyj liczby mnogiej (users), a dla pojedynczego elementu pojedynczej, żeby for (const user of users) czytało się naturalnie. Obiekt do wyszukiwania nazwij od jego klucza (usersById), a liczbę od tego, co zlicza (userCount). W Reakcie dokumentacja opisuje popularną konwencję dla zdarzeń: procedury obsługi nazywa się handle plus zdarzenie (handleClick), a właściwości (props) przyjmujące taką procedurę zaczynają się od on i wielkiej litery (onClick, onSave).

PascalCase dla klas, konstruktorów i komponentów

Wszystko, co tworzysz przez new, dostaje PascalCase, tak samo jak wszystko, co React renderuje jako komponent:

class ShoppingCart {
  addItem(item) {
    // ...
  }
}
const cart = new ShoppingCart();

function OrderSummary({ order }) {
  return <section>{order.id}</section>;
}

W przypadku klas to konwencja. W Reakcie to wymóg: dokumentacja Reacta mówi, że nazwy komponentów muszą zaczynać się wielką literą, bo inaczej nie zadziałają, ponieważ JSX traktuje znaczniki pisane małymi literami, takie jak <section>, jak zwykłe elementy HTML. W TypeScripcie ten sam PascalCase stosuje się do interfejsów, aliasów typów i enumów.

Wbudowane elementy wzorcowo to pokazują. Konstruktory są w PascalCase (Map, Promise, Date), metody w camelCase (Object.fromEntries, Array.prototype.flatMap), a stałe wartości wielkimi literami (Math.PI, Number.MAX_SAFE_INTEGER).

Kiedy używać CONSTANT_CASE (a kiedy nie)

Stałe wywołują najwięcej zamieszania, bo const nie znaczy „stała”. Zabrania tylko ponownego przypisania zmiennej; tablica lub obiekt, na który wskazuje, nadal może się zmieniać. Oba duże przewodniki stylu rezerwują wielkie litery dla czegoś ściślejszego:

• Google: CONSTANT_CASE jest dla wartości na poziomie modułu (i właściwości statycznych), które są głęboko niezmienne. Samo zamierzanie, by obiektu nigdy nie zmieniać, nie wystarcza, a stałe deklarowane wewnątrz funkcji pozostają w lowerCamelCase.
• Airbnb: wielkie litery są opcjonalne i tylko dla wartości, która jest eksportowana, zadeklarowana przez const i której można zaufać (łącznie z zagnieżdżonymi właściwościami), że nigdy się nie zmieni. Zapisywanie wielkimi literami każdego const w pliku jest niepotrzebne.

// Module level, never changes: capitals
export const MAX_UPLOAD_BYTES = 5 * 1024 * 1024;
export const ORDER_STATUS = Object.freeze({ PENDING: "pending", SHIPPED: "shipped" });

function visibleNames(items) {
  const visible = items.filter((item) => !item.hidden); // const, but not a constant
  const names = [];                                     // const binding, mutable array
  for (const item of visible) names.push(item.name);
  return names;
}

Przewodniki rozchodzą się co do kluczy obiektu przypominającego enum. Google zapisuje składowe enuma w CONSTANT_CASE, jak wyżej; Airbnb woli małe litery w kluczach wewnątrz eksportu pisanego wielkimi. Obie wersje są w porządku, jeśli cała baza kodu robi tak samo. Jeszcze jeden haczyk: Object.freeze jest płytkie, więc zamrożony obiekt nadal może zawierać zagnieżdżony obiekt, który się zmienia.

Pola prywatne: używaj #, nie podkreślnika

Stary zwyczaj oznaczania „prywatnych” składowych wiodącym podkreślnikiem (this._count) to tylko wskazówka; każdy nadal może odczytać i zapisać tę właściwość. Przewodnik Airbnb mówi, by nie używać wiodących ani końcowych podkreślników właśnie z tego powodu, a przewodnik Google do TypeScriptu zakazuje ich też jako prefiksów i sufiksów. Nowoczesny JavaScript ma prawdziwe pola prywatne:

class Counter {
  #count = 0;
  increment() {
    return ++this.#count;
  }
}

const counter = new Counter();
counter.increment();
counter.count;   // undefined
// counter.#count  // SyntaxError outside the class

Skróty: userId czy userID?

Reguła Google to traktowanie skrótów jak zwykłych wyrazów: customerId, xmlHttpRequest, loadHttpUrl. Reguła Airbnb jest odwrotna: skrót zostaje w całości wielkimi albo w całości małymi literami, jak w SMSContainer czy httpRequests. Sama przeglądarka nie potrafi się zdecydować: XMLHttpRequest, innerHTML, getElementById i encodeURIComponent istnieją na tej samej platformie.

My wybralibyśmy regułę Google, bo jest przewidywalna, zachowuje widoczne granice wyrazów i czysto konwertuje się między stylami wielkości liter. Ale spójność liczy się bardziej niż sam wybór. Reguły dotyczące skrótów we wszystkich głównych przewodnikach porównujemy we wpisie camelCase a PascalCase.

Obsługa danych w snake_case z API

API oparte na Pythonie, Rubym lub bazie SQL często zwracają klucze takie jak first_name. Nie pozwól im rozlać się po kodzie. Zmień nazwy w miejscu, w którym dane docierają, a destrukturyzacja robi z tego jedną linijkę:

const response = await fetch("/api/users/42");
const { first_name: firstName, last_login: lastLogin } = await response.json();

Dla całych ładunków danych napisz małą funkcję dla każdego kierunku, która rekurencyjnie konwertuje klucze, i wywołuj ją w kliencie API; jedną z nich omawiamy w poradniku o zamianie kluczy JSON z camelCase na snake_case. Dla jednorazowej zmiany nazwy nasz konwerter wielkości liter zamienia last_login na lastLogin jednym kliknięciem.

Wymuś to przez ESLint

Dwie podstawowe reguły ESLint obejmują większość tych zasad. camelcase zgłasza podkreślniki w środku nazw, pomijając stałe pisane wielkimi literami oraz wiodące i końcowe podkreślniki. new-cap zgłasza new użyte z nazwą pisaną małą literą oraz funkcję pisaną wielką literą wywołaną bez new.

// eslint.config.js
export default [
  {
    rules: {
      camelcase: ["error", { properties: "never" }],
      "new-cap": "error",
    },
  },
];

Opcja properties: "never" sprawia, że camelcase przestaje narzekać na pola API takie jak data.first_name, a nadal sprawdza zmienne, które sam deklarujesz. W projektach TypeScript @typescript-eslint/naming-convention idzie dalej: pozwala ustawić dozwolony format dla każdego rodzaju identyfikatora: zmiennych, funkcji, klas, parametrów typów i innych. Pełny zestaw reguł Google znajdziesz w Google JavaScript Style Guide.

Lista kontrolna nazewnictwa zmiennych w JavaScripcie

• camelCase dla zmiennych, funkcji, parametrów, metod i właściwości.
• PascalCase dla klas, konstruktorów, komponentów Reacta oraz typów, interfejsów i enumów w TypeScripcie.
• CONSTANT_CASE dla wartości na poziomie modułu, które nigdy się nie zmieniają, a nie dla każdego const.
• Pola #private zamiast prefiksów z podkreślnikiem.
• Jedna reguła dla skrótów, zapisana w przewodniku dla współtwórców projektu.
• Klucze API w snake_case konwertowane raz, na granicy.