← Blog · 30. April 2026 · ConvertCaseHQ-Team · 6 Min. Lesezeit

camelCase vs. PascalCase: Was ist der Unterschied?

Der einzige Unterschied zwischen camelCase und PascalCase ist der erste Buchstabe. camelCase beginnt klein und schreibt jedes weitere Wort groß (userName, parseResponse). PascalCase schreibt jedes Wort groß, auch das erste (UserName, ResponseParser). Üblicherweise kennzeichnet PascalCase Typen (Klassen, Interfaces, Enums, React-Komponenten) und camelCase Werte und Aktionen (Variablen, Funktionen, Methoden, Eigenschaften).

Dieser eine Großbuchstabe sagt mehr aus, als man ihm ansieht. Hier erfährst du, was er anzeigt, in welchen Sprachen er nicht nur eine höfliche Konvention ist, sondern durchgesetzt wird, und worüber sich niemand einig ist: Akronyme.

camelCase vs. PascalCase auf einen Blick

Achte beim Lesen von Styleguides auf die Begriffe. Viele Leute sagen „Camel Case“ für beide Stile, und PEP 8 führt sogar CamelCase als weiteren Namen für CapWords auf, seinen Begriff für PascalCase. Wenn nicht klar ist, was ein Styleguide meint, schau dir seine Beispiele an.

Warum der erste Buchstabe zählt: Typen vs. Werte

Die Konvention lässt dich Code lesen, ohne etwas nachschlagen zu müssen. In const invoice = new Invoice(order) siehst du auf einen Blick, dass Invoice das ist, was du erzeugst, und invoice das, was du zurückbekommst. TypeScript-Signaturen funktionieren genauso: In function total(order: Order): Money ist der kleingeschriebene Name der Wert, und die großgeschriebenen Namen sind Typen.

Außerdem kann ein und dasselbe Wort einen Typ und einen Wert benennen, ohne dass es zu einem Konflikt kommt, und das kommt ständig vor: user: User, config: Config, request: Request. In einer Sprache, die zwischen Groß- und Kleinschreibung unterscheidet, sind das verschiedene Bezeichner, und der Großbuchstabe sagt dem Leser, welcher welcher ist.

Wo die Sprache es erzwingt

In JavaScript, Java, C# und Python ist die Schreibweise eines Klassennamens nur eine Konvention. Nichts hindert dich daran, class invoice zu schreiben. In JavaScript kannst du die Konvention mit der ESLint-Regel new-cap zu einer Prüfung machen: Standardmäßig meldet sie new invoice(), und sie meldet auch den Aufruf einer großgeschriebenen Funktion wie Invoice() ohne new, was meistens ein Fehler ist. Einige Sprachen und Frameworks gehen weiter und bauen die Regel fest ein.

Go: Der erste Buchstabe ist die Sichtbarkeitsregel

Go kennt weder public noch private als Schlüsselwort. Ein Name auf Paketebene, ein Struct-Feld oder eine Methode wird exportiert, wenn der erste Buchstabe groß ist, und bleibt privat in seinem Paket, wenn er klein ist. Mit PascalCase oder camelCase legst du also die Sichtbarkeit fest.

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

Deshalb soll nach Effective Go auch ein Getter für ein nicht exportiertes Feld owner Owner heißen und nicht GetOwner. Der Großbuchstabe zeigt schon an, dass es der öffentliche Zugang ist.

React: Komponenten müssen großgeschrieben werden

Die React-Dokumentation ist da unmissverständlich: Komponentennamen müssen mit einem Großbuchstaben beginnen, sonst funktionieren sie nicht. JSX behandelt ein kleingeschriebenes Tag wie <section> als HTML-Element und ein großgeschriebenes wie <OrderSummary /> als deine Komponente.

Ruby: Klassennamen sind Konstanten

In Ruby ist jeder Name, der mit einem Großbuchstaben beginnt, eine Konstante, und Klassennamen müssen Konstanten sein. class Invoice funktioniert; class invoice ist ein Syntaxfehler (Meldung: „class/module name must be CONSTANT“).

Welcher Stil in welcher Sprache

• JavaScript und TypeScript: camelCase für Variablen, Funktionen, Methoden und Eigenschaften; PascalCase für Klassen, Interfaces, Typ-Aliasse, Enums und Komponenten.
• Java und Kotlin: dieselbe Aufteilung, dazu Großbuchstaben mit Unterstrichen für echte Konstanten (MAX_RETRIES).
• C#: PascalCase ist hier deutlich verbreiteter als in anderen Sprachen. Methoden, Eigenschaften, Events, öffentliche Felder, Namespaces und sogar Konstanten stehen in PascalCase; camelCase gilt für Parameter und lokale Variablen, _camelCase für private Felder. Eine typische Signatur sieht so aus: public decimal CalculateTotal(decimal taxRate).
• Swift: PascalCase für Typen und Protokolle, camelCase für alles andere.
• Go: je nachdem, welche Sichtbarkeit du willst.
• Python: PascalCase nur für Klassen. Funktionen und Variablen stehen in snake_case, und PEP 8 erlaubt camelCase nur dort, wo es in älterem Code ohnehin der vorherrschende Stil ist.
• PHP (PSR-1): Klassen in PascalCase, Methoden in camelCase.

Zu Konstanten, Dateien und allem Übrigen findest du mehr in unserem Spickzettel für Namenskonventionen.

Der schwierige Teil: Akronyme und Initialwörter

Heißt es userId oder userID? HttpClient oder HTTPClient? Die großen Styleguides geben unterschiedliche Antworten:

Unsere Empfehlung: Wenn der Styleguide deiner Sprache eine Regel hat, halte dich daran, denn das erwarten die Standardbibliothek und dein Team. Wenn nicht, behandle Akronyme wie Wörter (HttpClient, userId). So bleiben die Wortgrenzen sichtbar, wenn zwei Akronyme aufeinandertreffen (vergleiche XMLHTTPRequest mit XmlHttpRequest), und die Namen überstehen die automatische Umwandlung zwischen Schreibweisen. Selbst das XMLHttpRequest des Browsers mischt beide Ansätze in einem Namen.

Zum Weiterlesen: Microsofts Konventionen zur Groß- und Kleinschreibung sind ein gutes Beispiel für ein vollständiges Regelwerk, das auf einer einzigen Seite steht.

camelCase und PascalCase ineinander umwandeln

Bei einem einfachen Namen ist die Umwandlung ein einziges Zeichen: Du änderst die Schreibweise des ersten Buchstabens.

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)

Wegen dieser letzten Zeile zerlegen Tools Namen zuerst in Wörter. So wandelt der Case-Konverter von ConvertCaseHQ einige knifflige Eingaben um:

Er trennt an vorhandenen Großbuchstaben und schreibt Akronyme wie Wörter, was zu Googles Regel passt. Folgt dein Projekt den Akronym-Regeln von Go, .NET oder PEP 8, korrigiere diese Namen anschließend von Hand (getUserId wird in Go zu getUserID). Markennamen sind die andere Falle: Kein Algorithmus weiß, dass IPhone falsch aussieht.

Zwei Ausrutscher, die du vermeiden solltest

Der erste ist, eine Instanz großzuschreiben: const Cart = new ShoppingCart() lässt Cart wie eine zweite Klasse aussehen, und der nächste Leser sucht nach ihrer Definition. Der zweite ist eine Hilfsfunktion in PascalCase in JavaScript, etwa function FormatPrice(). Wenn sie kein Konstruktor und keine React-Komponente ist, gehen Leser davon aus, dass sie new oder JSX braucht, und new-cap beschwert sich, wenn du sie mit keinem von beiden aufrufst.

Eine Faustregel

Wenn es ein Typ ist oder etwas, das du mit new erzeugst, nimm PascalCase. Wenn es ein Wert oder eine Aktion ist, nimm camelCase. Überlass die Akronyme dem Styleguide deiner Sprache und den Rest einem Linter. Details zu JavaScript, auch zu Konstanten und privaten Feldern, findest du in unserem Leitfaden zur Benennung in JavaScript.