← Blog · 16. April 2026 · ConvertCaseHQ-Team · 7 Min. Lesezeit

JavaScript-Variablen benennen: Leitfaden zu camelCase und Konventionen

In JavaScript benennst du Variablen, Funktionen, Parameter und Objekteigenschaften in camelCase (cartTotal, fetchOrders), Klassen und React-Komponenten in PascalCase (ShoppingCart) und hebst dir CONSTANT_CASE für Werte auf, die für die gesamte Laufzeit des Programms feststehen (MAX_RETRIES). In diesem Punkt stimmen die JavaScript-Styleguides von Google und Airbnb überein, und auch die eingebauten Objekte von JavaScript folgen demselben Muster.

Der Rest dieses Leitfadens behandelt zuerst, was die Engine tatsächlich erzwingt, dann die Konventionen darüber und schließlich die Randfälle, bei denen Teams uneins sind: welche const-Werte Großbuchstaben verdienen, private Felder, Abkürzungen und snake_case-Daten, die von einer API kommen.

Was JavaScript selbst erlaubt

Die Regeln der Sprache sind kurz. Ein Bezeichner beginnt mit einem Buchstaben, einem Unterstrich oder einem Dollarzeichen, und die weiteren Zeichen dürfen auch Ziffern sein. Buchstaben sind nicht auf ASCII beschränkt: MDNs eigenes Beispiel ist das deutsche Wort Früh. Namen unterscheiden Groß- und Kleinschreibung, total und Total sind also zwei verschiedene Variablen, und reservierte Wörter wie new, class und delete lassen sich nicht als Variablennamen verwenden.

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

Bei Eigenschaftsnamen ist es noch lockerer: Jeder String funktioniert, wenn du ihn in Anführungszeichen setzt, und so ist headers["Content-Type"] möglich. Alles jenseits dieser Regeln ist Konvention, und genau deshalb lohnt es sich, sich darauf zu einigen.

camelCase für Variablen, Funktionen und Eigenschaften

camelCase ist der Standard für fast alles, was du in JavaScript benennst. Gib Werten Substantive als Namen und Funktionen Verben, damit sich eine Zeile wie ein Satz liest:

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

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

Bei Booleans beantwortet ein Präfix wie is, has oder can (isLoggedIn, hasAccess) die Frage „Was ist hier wahr oder falsch?“, bevor jemand sie stellen muss. Googles Leitfaden verwendet dieselben Präfixe für boolesche Getter (isFoo, hasFoo).

Googles Leitfaden hat außerdem eine gute Regel zur Länge: Sei so beschreibend, wie es vernünftig ist, und kürze nicht, indem du Buchstaben weglässt. errorCount und customerId gehen durch; nErr und cstmrId nicht. Die Ausnahme des Leitfadens ist eine Variable, deren Gültigkeitsbereich zehn Zeilen oder weniger umfasst, etwa das i in einer kurzen Schleife oder das x in points.map((x) => x * 2).

Sammlungen, Zähler und Event-Handler

Ein paar Muster machen Namen vorhersehbar. Nimm den Plural für ein Array (users) und den Singular für ein einzelnes Element, damit sich for (const user of users) natürlich liest. Benenne ein Lookup-Objekt nach seinem Schlüssel (usersById) und eine Zahl nach dem, was sie zählt (userCount). In React beschreibt die Dokumentation eine verbreitete Konvention für Events: Handler heißen handle plus Event (handleClick), und Props, die einen Handler annehmen, beginnen mit on und einem Großbuchstaben (onClick, onSave).

PascalCase für Klassen, Konstruktoren und Komponenten

Alles, was du mit new erzeugst, bekommt PascalCase, und ebenso alles, was React als Komponente rendert:

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

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

Bei Klassen ist es Konvention. Bei React ist es Pflicht: Laut React-Dokumentation müssen Komponentennamen mit einem Großbuchstaben beginnen, sonst funktionieren sie nicht, weil JSX Tags in Kleinbuchstaben wie <section> als gewöhnliche HTML-Elemente behandelt. In TypeScript steht dasselbe PascalCase auch bei Interfaces, Typaliasen und Enums.

Die eingebauten Objekte zeigen das alles vor. Konstruktoren stehen in PascalCase (Map, Promise, Date), Methoden in camelCase (Object.fromEntries, Array.prototype.flatMap) und feste Werte in Großbuchstaben (Math.PI, Number.MAX_SAFE_INTEGER).

Wann CONSTANT_CASE (und wann nicht)

Konstanten sorgen für die meiste Verwirrung, denn const bedeutet nicht „konstant“. Es verhindert nur, dass die Variable neu zugewiesen wird; das Array oder Objekt, auf das sie zeigt, kann sich trotzdem ändern. Beide großen Styleguides reservieren Großbuchstaben für etwas Strengeres:

Google: CONSTANT_CASE gilt für Werte auf Modulebene (und statische Eigenschaften), die tief unveränderlich sind. Die bloße Absicht, ein Objekt nie zu ändern, reicht nicht, und Konstanten, die innerhalb von Funktionen deklariert werden, bleiben in lowerCamelCase.
Airbnb: Großbuchstaben sind optional und nur für einen Wert gedacht, der exportiert und mit const deklariert ist und dem man zutrauen kann (verschachtelte Eigenschaften eingeschlossen), sich nie zu ändern. Jedes const in einer Datei in Großbuchstaben zu schreiben ist unnötig.

// 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;
}

Bei den Schlüsseln eines enum-ähnlichen Objekts gehen die beiden Styleguides getrennte Wege. Google schreibt Enum-Member in CONSTANT_CASE, wie oben; Airbnb bevorzugt Schlüssel in Kleinbuchstaben innerhalb eines Exports in Großbuchstaben. Beides ist in Ordnung, wenn die ganze Codebasis es gleich macht. Noch ein Haken: Object.freeze wirkt nur oberflächlich, ein eingefrorenes Objekt kann also trotzdem ein verschachteltes Objekt enthalten, das sich ändert.

Private Felder: # statt Unterstrich

Die alte Angewohnheit, „private“ Member mit einem führenden Unterstrich zu markieren (this._count), ist nur ein Hinweis; jeder kann die Eigenschaft trotzdem lesen und schreiben. Airbnbs Leitfaden sagt aus genau diesem Grund, dass man keine führenden oder nachgestellten Unterstriche verwenden soll, und auch Googles TypeScript-Leitfaden verbietet sie als Präfix und Suffix. Modernes JavaScript hat echte private Felder:

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

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

Abkürzungen: userId oder userID?

Googles Regel lautet, Abkürzungen wie gewöhnliche Wörter zu behandeln: customerId, xmlHttpRequest, loadHttpUrl. Airbnb sagt das Gegenteil: Eine Abkürzung bleibt komplett in Großbuchstaben oder komplett in Kleinbuchstaben, wie bei SMSContainer oder httpRequests. Der Browser selbst kann sich nicht entscheiden: XMLHttpRequest, innerHTML, getElementById und encodeURIComponent stehen alle in derselben Plattform.

Wir würden Googles Regel wählen, weil sie vorhersehbar ist, Wortgrenzen sichtbar hält und sich sauber zwischen Schreibweisen umwandeln lässt. Wichtiger als die Wahl ist aber die Einheitlichkeit. Die Abkürzungsregeln aller großen Styleguides vergleichen wir in camelCase vs. PascalCase.

snake_case-Daten aus APIs verarbeiten

APIs, die auf Python, Ruby oder einer SQL-Datenbank basieren, liefern oft Schlüssel wie first_name. Lass sie sich nicht durch deinen Code ausbreiten. Benenne an der Stelle um, an der die Daten ankommen; mit Destructuring ist das ein Einzeiler:

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

Für ganze Payloads schreibst du für jede Richtung eine kleine Funktion, die Schlüssel rekursiv umwandelt, und rufst sie in deinem API-Client auf; eine davon gehen wir in camelCase-JSON in snake_case umwandeln durch. Für eine einmalige Umbenennung macht unser Case-Konverter aus last_login mit einem Klick lastLogin.

Mit ESLint durchsetzen

Zwei Kernregeln von ESLint decken das meiste davon ab. camelcase markiert Unterstriche mitten in Namen und ignoriert dabei Konstanten in Großbuchstaben sowie führende oder nachgestellte Unterstriche. new-cap markiert new mit einem kleingeschriebenen Namen und eine großgeschriebene Funktion, die ohne new aufgerufen wird.

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

Die Option properties: "never" hält camelcase davon ab, sich über API-Felder wie data.first_name zu beschweren, prüft aber weiterhin die Variablen, die du selbst deklarierst. In TypeScript-Projekten geht @typescript-eslint/naming-convention weiter und lässt dich für jede Art von Bezeichner ein erlaubtes Format festlegen: Variablen, Funktionen, Klassen, Typparameter und mehr. Alle Regeln von Google stehen im Google JavaScript Style Guide.

Checkliste: JavaScript-Variablen benennen

camelCase für Variablen, Funktionen, Parameter, Methoden und Eigenschaften.
PascalCase für Klassen, Konstruktoren, React-Komponenten sowie TypeScript-Typen, Interfaces und Enums.
CONSTANT_CASE für Werte auf Modulebene, die sich nie ändern, nicht für jedes const.
#private-Felder statt Unterstrich-Präfixen.
Eine Regel für Abkürzungen, festgehalten in deinem Contributing-Guide.
snake_case-API-Schlüssel einmal umwandeln, an der Systemgrenze.