← Blog · · ConvertCaseHQ-team · 7 min lezen

Naamgeving van variabelen in JavaScript: gids voor camelCase en andere conventies

Geef in JavaScript variabelen, functies, parameters en objecteigenschappen een naam in camelCase (cartTotal, fetchOrders), klassen en React-componenten in PascalCase (ShoppingCart), en bewaar CONSTANT_CASE voor waarden die tijdens de hele looptijd van het programma vastliggen (MAX_RETRIES). De JavaScript-stijlgidsen van Google en Airbnb zijn het daar zo ver over eens, en de ingebouwde objecten van JavaScript zelf volgen hetzelfde patroon.

De rest van deze gids behandelt eerst wat de engine echt afdwingt, dan de conventies daarbovenop, en dan de randgevallen waarover teams het oneens zijn: welke const-waarden hoofdletters verdienen, private velden, afkortingen en snake_case-data die uit een API komt.

Wat JavaScript zelf toestaat

De regels van de taal zijn kort. Een identifier begint met een letter, een underscore of een dollarteken, en latere tekens mogen ook cijfers zijn. Letters zijn niet beperkt tot ASCII: het eigen voorbeeld van MDN is het Duitse woord Früh. Namen zijn hoofdlettergevoelig, dus total en Total zijn twee verschillende variabelen, en gereserveerde woorden zoals new, class en delete kunnen niet als variabelenaam worden gebruikt.

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

Eigenschapsnamen zijn nog ruimer: elke string werkt als je hem tussen aanhalingstekens zet, waardoor headers["Content-Type"] mogelijk is. Alles buiten deze regels is conventie, en juist daarom loont het om er afspraken over te maken.

camelCase voor variabelen, functies en eigenschappen

camelCase is de standaard voor bijna alles wat je in JavaScript een naam geeft. Geef waarden een naam als zelfstandig naamwoord en functies een naam als werkwoord, zodat een regel als een zin leest:

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

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

Bij booleans beantwoordt een voorvoegsel is, has of can (isLoggedIn, hasAccess) de vraag “waar of niet waar, van wat?” voordat iemand die hoeft te stellen. De gids van Google gebruikt dezelfde voorvoegsels voor boolean-getters (isFoo, hasFoo).

De gids van Google heeft ook een goede regel over lengte: wees zo beschrijvend als redelijk is en kort niet af door letters weg te laten. errorCount en customerId mogen; nErr en cstmrId niet. De uitzondering van de gids is een variabele met een scope van tien regels of minder, zoals de i in een korte lus of de x in points.map((x) => x * 2).

Collecties, tellers en event handlers

Een paar patronen maken namen voorspelbaar. Gebruik een meervoud voor een array (users) en het enkelvoud voor één item, zodat for (const user of users) natuurlijk leest. Noem een opzoekobject naar zijn sleutel (usersById) en een getal naar wat het telt (userCount). In React beschrijft de documentatie een gangbare conventie voor events: handlers heten handle plus het event (handleClick), en props die een handler accepteren beginnen met on en een hoofdletter (onClick, onSave).

PascalCase voor klassen, constructors en componenten

Alles wat je met new aanmaakt, krijgt PascalCase, en ook alles wat React als component rendert:

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

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

Bij klassen is het een conventie. Bij React is het verplicht: de React-documentatie zegt dat namen van componenten met een hoofdletter moeten beginnen, anders werken ze niet, omdat JSX tags met kleine letters zoals <section> behandelt als gewone HTML-elementen. In TypeScript gebruik je hetzelfde PascalCase voor interfaces, type-aliassen en enums.

De ingebouwde objecten laten dit allemaal zien. Constructors zijn PascalCase (Map, Promise, Date), methoden zijn camelCase (Object.fromEntries, Array.prototype.flatMap) en vaste waarden staan in hoofdletters (Math.PI, Number.MAX_SAFE_INTEGER).

Wanneer je CONSTANT_CASE gebruikt (en wanneer niet)

Constanten zorgen voor de meeste verwarring, omdat const niet “constant” betekent. Het voorkomt alleen dat de variabele opnieuw wordt toegewezen; de array of het object waarnaar hij verwijst kan nog steeds veranderen. Beide grote stijlgidsen reserveren hoofdletters voor iets strengers:

  • Google: CONSTANT_CASE is voor waarden op moduleniveau (en statische eigenschappen) die volledig onveranderlijk zijn (deeply immutable). Het enkele voornemen om een object nooit te veranderen is niet genoeg, en constanten die binnen functies worden gedeclareerd blijven lowerCamelCase.
  • Airbnb: hoofdletters zijn optioneel, en alleen voor een waarde die wordt geëxporteerd, met const is gedeclareerd en waarvan je erop kunt vertrouwen (geneste eigenschappen inbegrepen) dat hij nooit verandert. Elke const in een bestand in hoofdletters zetten is onnodig.
// 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;
}

De gidsen gaan uiteen over de sleutels van een enum-achtig object. Google schrijft enum-leden in CONSTANT_CASE, zoals hierboven; Airbnb geeft de voorkeur aan sleutels in kleine letters binnen een export in hoofdletters. Allebei is prima als de hele codebase hetzelfde doet. Nog een addertje: Object.freeze is oppervlakkig (shallow), dus een bevroren object kan nog steeds een genest object bevatten dat verandert.

Private velden: gebruik #, geen underscore

De oude gewoonte om “private” leden te markeren met een underscore vooraan (this._count) is slechts een hint; iedereen kan de eigenschap nog steeds lezen en schrijven. De gids van Airbnb zegt om precies die reden geen underscores vooraan of achteraan te gebruiken, en de TypeScript-gids van Google verbiedt ze ook als voor- en achtervoegsel. Modern JavaScript heeft echte private velden:

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

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

Afkortingen: userId of userID?

De regel van Google is afkortingen als gewone woorden te behandelen: customerId, xmlHttpRequest, loadHttpUrl. Die van Airbnb is het tegenovergestelde: houd een afkorting geheel in hoofdletters of geheel in kleine letters, zoals in SMSContainer of httpRequests. De browser zelf kan er niet over beslissen, want XMLHttpRequest, innerHTML, getElementById en encodeURIComponent zitten allemaal op hetzelfde platform.

Wij zouden de regel van Google kiezen, omdat hij voorspelbaar is, woordgrenzen zichtbaar houdt en netjes omzet tussen stijlen. Maar consistentie is belangrijker dan de keuze. We vergelijken de afkortingsregel van elke grote gids in camelCase of PascalCase.

snake_case-data uit API's verwerken

API's die door Python, Ruby of een SQL-database worden gevoed, geven je vaak sleutels als first_name. Laat die zich niet door je code verspreiden. Hernoem ze op het punt waar de data binnenkomt; met destructuring is dat een one-liner:

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

Voor complete payloads schrijf je voor elke richting een kleine functie die sleutels recursief omzet en die je aanroept in je API-client; we lopen er een door in camelCase-JSON omzetten naar snake_case. Voor een eenmalige hernoeming zet onze hoofdletter-converter last_login met één klik om in lastLogin.

Afdwingen met ESLint

Twee kernregels van ESLint dekken het meeste hiervan. camelcase markeert underscores midden in namen en negeert constanten in hoofdletters en underscores vooraan of achteraan. new-cap markeert new met een naam die met een kleine letter begint, en een functie met een hoofdletter die zonder new wordt aangeroepen.

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

De optie properties: "never" zorgt dat camelcase niet klaagt over API-velden als data.first_name, terwijl de variabelen die je zelf declareert wel worden gecontroleerd. In TypeScript-projecten gaat @typescript-eslint/naming-convention verder: daarmee stel je per soort identifier een toegestaan formaat in, voor variabelen, functies, klassen, typeparameters en meer. De volledige set regels van Google staat in de Google JavaScript Style Guide.

Een checklist voor het benoemen van JavaScript-variabelen

  • camelCase voor variabelen, functies, parameters, methoden en eigenschappen.
  • PascalCase voor klassen, constructors, React-componenten en TypeScript-types, -interfaces en -enums.
  • CONSTANT_CASE voor waarden op moduleniveau die nooit veranderen, niet voor elke const.
  • #private-velden in plaats van underscore-voorvoegsels.
  • Eén afkortingsregel, opgeschreven in de richtlijnen voor bijdragers van je project.
  • snake_case-sleutels uit een API één keer omgezet, aan de rand van je code.

© 2026 ConvertCaseHQ. Alle rechten voorbehouden.