CamelCase richtig nutzen: Beispiele, Regeln, SEO-Tipps

Ein Entwickler tippt getUserData in seinen Editor. Drei Wörter, eine Notation, kein Zweifel. Ein anderer schreibt im selben Moment get_user_data. Ein dritter GetUserData. Alle drei meinen dasselbe. Alle drei verraten, in welchem Ökosystem sie zuhause sind.

Schreibweisen sind keine Geschmacksfrage. Sie sind Zugehörigkeit.

Illustration zu CamelCase mit Kamelhöckern, Binnenmajuskeln, Codebeispielen wie getUserData und dem Hinweis nicht in URLs.

CamelCase markiert Wortgrenzen ohne Leerzeichen durch Großbuchstaben im Wortinneren und wird häufig in Code, APIs und Hashtags genutzt.

Definition

CamelCase bezeichnet eine Schreibweise, bei der mehrere Wörter ohne Leerzeichen aneinandergereiht werden und Wortgrenzen durch Binnenmajuskeln (Großbuchstaben im Wortinneren) markiert sind. Die Großbuchstaben stehen wie kleine Höcker im Buchstabenstrom – daher der Name. Übliche Varianten sind lowerCamelCase (erstes Wort klein, z. B. pageTitle) und UpperCamelCase bzw. PascalCase (erstes Wort groß, z. B. PageTitle).

Woher der Name kommt

Die Großbuchstaben mitten im Wort erinnern an die Höcker eines Kamels. Manche Quellen verwenden auch den Begriff StudlyCaps, der allerdings eine uneinheitliche, eher dekorative Groß-/Kleinschreibung beschreibt und in technischen Kontexten unüblich ist. Die beiden produktiven Bezeichnungen lauten lowerCamelCase und PascalCase (synonym: UpperCamelCase). Sie unterscheiden sich nur in einer Frage: Wird das erste Wort großgeschrieben oder nicht?

Die Varianten im Überblick

lowerCamelCase: erstes Wort klein, jede weitere Wortgrenze mit Großbuchstaben (firstName, getUserData).
UpperCamelCase / PascalCase: jedes Wort mit Großbuchstaben (FirstName, GetUserData).
StudlyCaps: unregelmäßige Groß-/Kleinschreibung für seriöse Anwendungen nicht zu empfehlen.

Zur Abgrenzung von verwandten Notationen:

snake_case nutzt Unterstriche.
kebab-case nutzt Bindestriche.
SCREAMING_SNAKE_CASE ist die typische Schreibweise für Konstanten.

Diese Terminologie ist in Dokumentation und Styleguides etabliert (u. a. MDN und ESLint).

Wo CamelCase Standard ist – Sprache für Sprache

CamelCase ist keine Geschmacksrichtung. In vielen Sprachen ist sie vorgeschrieben. Wer dagegen schreibt, dokumentiert nicht Originalität, sondern Unkenntnis der Konvention.

Swift (Apple)

Die offiziellen Swift API Design Guidelines verlangen UpperCamelCase für Typen (Klassen, Strukturen, Enums) und lowerCamelCase für Funktionen, Methoden und Eigenschaften. Ziel: konsistente Lesbarkeit über das gesamte Ökosystem hinweg.

.NET / C# (Microsoft)

Die Framework-Design-Guidelines trennen sauber: Öffentliche Typen und Member verwenden PascalCase, lokale Variablen und Parameter camelCase. JSON-Feldnamen lassen sich per Naming-Policy automatisiert in camelCase transformieren.

JavaScript / DOM-APIs

Viele DOM-Eigenschaften entsprechen camelCase-Schreibweisen: Aus der CSS-Property background-color wird im JavaScript-DOM backgroundColor. Dieses Mapping ist in der MDN-Dokumentation festgehalten.

Go

Go verwendet MixedCaps. Exportierte Bezeichner beginnen mit Großbuchstaben (ExportedName), nicht exportierte mit Kleinbuchstaben (internalName). Eine Besonderheit: Initialisms wie HTTP, URL, JSON bleiben durchgehend groß. Also HTTPServer, nicht HttpServer. parseURL, nicht parseUrl. Diese Regeln sind in Effective Go und den Code Review Comments verankert.

Python

PEP 8 bricht mit dem Muster: CapWords (also PascalCase) für Klassennamen, aber snake_case für Funktionen und Variablen. CamelCase ist im Python-Stil nicht Standard für Funktionsnamen. Wer dort camelCase schreibt, signalisiert Java-Vergangenheit.

Die Faustregel lautet: Folgen Sie der Konvention der jeweiligen Sprache. Sie ist wichtiger als persönliche Vorlieben. Lesbarkeit, Tooling und Team-Kohärenz hängen daran. Für JavaScript erzwingen ESLint-Regeln wie camelcase die Einhaltung automatisiert.

DOM, CSS und dataset

Im Frontend ist CamelCase überall, sobald JavaScript ins Spiel kommt.

Style-Eigenschaften:

element.style.backgroundColor = 'red';

element.style.borderTopLeftRadius = '4px';

Aus jedem CSS-Property mit Bindestrich wird im DOM eine camelCase-Eigenschaft. Die MDN dokumentiert das Mapping systematisch.

Die dataset-API: data-*-Attribute werden als camelCase-Eigenschaften zugänglich. Aus data-user-id wird element.dataset.userId. Aus data-date-of-birth wird element.dataset.dateOfBirth. Die MDN-Spezifikation beschreibt das bidirektionale Mapping: Bindestriche entfallen, der nachfolgende Buchstabe wird groß.

JSON und APIs: keine universelle Norm

Hier wird es unübersichtlich. Einen verbindlichen Standard für JSON-Schlüsselnamen gibt es nicht. Viele Web-APIs nutzen camelCase (insbesondere im JavaScript-Umfeld), andere bevorzugen snake_case oder kebab-case.

Was zählt: Konsistenz innerhalb der API und die Passung zum Ziel-Stack. In .NET kann System.Text.Json Membernamen über Naming Policies automatisch in camelCase konvertieren. Das JSON:API-Ökosystem empfiehlt in seinen Recommendations URL-taugliche Membernamen, in der Praxis oft kebab-case.

Die Frage „camelCase oder snake_case?“ hat keine richtige Antwort. Nur eine schlechte: keine Antwort. Wer mitten in einer API zwischen den Stilen wechselt, hinterlässt Fallstricke für jeden, der danach kommt.

CamelCase im Branding und in Hashtags

Zahlreiche Marken verwenden Binnenmajuskeln: YouTube, LinkedIn, iPhone, eBay. Was wie ein Designgriff aussieht, hat einen handfesten Effekt für die Wahrnehmung – das Auge erkennt Wortbestandteile sofort.

Bei Hashtags ist CamelCase nicht nur empfehlenswert. Es ist eine Frage der Barrierefreiheit. Screenreader erkennen Wortgrenzen besser, wenn jedes Wort mit einem Großbuchstaben beginnt. Aus #blacklivesmatter wird so #BlackLivesMatter. Aus einer für blinde Nutzer:innen unverständlichen Buchstabensuppe wird ein vorlesbarer Satz.

Öffentlich-rechtliche Leitfäden und Accessibility-Ressourcen empfehlen unisono: Jedes Wort im Hashtag großschreiben.

Praxisbeispiel:

Schwer lesbar: #unsereneuekampagne
Korrekt: #UnsereNeueKampagne

Eine Frage, die selten gestellt wird: Welche Hashtags Ihrer letzten Kampagne hätte ein Screenreader fehlerfrei vorgelesen?

SEO: Warum CamelCase in URLs nichts verloren hat

Jetzt zum heiklen Teil. Wer Code-Konventionen kennt, übernimmt sie reflexhaft auch für URLs. Das ist ein Fehler.

1) URLs und Slugs

Für SEO-freundliche URLs empfiehlt Google ausdrücklich Bindestriche als Worttrenner. Nicht CamelCase. Nicht Unterstriche. Bindestriche erleichtern Suchmaschinen wie Menschen das Erkennen einzelner Begriffe.

2) Groß-/Kleinschreibung als Stolperstein

Nach IETF STD 66 bzw. RFC 3986 sind Scheme und Host einer URL case-insensitiv. Pfad, Query und Fragment dagegen werden in der Regel case-sensitiv behandelt – serverabhängig. Google bestätigt: /APPLE und /apple gelten als verschiedene URLs.

Damit ist ein CamelCase-Slug ein hausgemachtes Duplikat-Risiko.

Best Practices für SEO-Slugs:

Konsequent kleine Buchstaben.
Bindestriche als Worttrenner: /fassadenreinigung-pforzheim/.
Keine CamelCase-Pfade.
Bei Umstellungen: 301-Weiterleitungen einrichten, Sitemap aktualisieren, Canonicals prüfen.

Internationalisierung: Wo CamelCase scheitert

CamelCase sieht einfach aus. Bis Unicode ins Spiel kommt.

Spezielle Groß-/Kleinschreibung

Das türkische İ/ı (mit und ohne Punkt), das griechische Σ/σ/ς mit seinem Sonderfall am Wortende, das deutsche ß/ẞ: Diese Zeichen haben kontext- oder sprachabhängige Fallregeln. Unicode SpecialCasing definiert vollständige Mappings, die weit über simple 1:1-Beziehungen hinausgehen.

Naive ASCII-Heuristiken? Reichen nicht.

Textsegmentierung

Wort-, Zeichen- und Graphem-Grenzen sind in Unicode nicht trivial. Wer CamelCase programmatisch zerlegen oder erzeugen will, sollte sich an UAX #29: Unicode Text Segmentation halten und entsprechende Bibliotheken nutzen (ICU, Intl.Segmenter).

Praxis-Tipp: Wenn Sie CamelCase programmatisch verarbeiten, vermeiden Sie Regexe, die nur [A-Z][a-z] antizipieren. Sie scheitern an diakritischen Zeichen und Mehrzeichen-Mappings. Lautlos. Reproduzierbar nur in der einen Edge-Sprache, die niemand getestet hat.

Code-Beispiele

CamelCase Unicode-aware verarbeiten:

// Vorsicht: naive Regexe brechen bei ß/İ/Σ etc.

// Besser: Intl.Segmenter für Wortgrenzen einsetzen

const segmenter = new Intl.Segmenter('de', { granularity: 'word' });

const words = [...segmenter.segment('FußballWeltmeisterschaft')]

.map(s => s.segment);

Serialisierung mit .NET:

var options = new JsonSerializerOptions {

PropertyNamingPolicy = JsonNamingPolicy.CamelCase

};

var json = JsonSerializer.Serialize(model, options);

Intern PascalCase, nach außen camelCase. Sauber.

DOM und dataset:

<div id="user" data-user-id="42" data-date-of-birth="1990-05-20"></div>

<script>

const el = document.getElementById('user');

console.log(el.dataset.userId);      // "42"

console.log(el.dataset.dateOfBirth); // "1990-05-20"

</script>

Go mit Initialisms:

type HTTPServer struct{}

func ParseURL(s string) (*URL, error) { /* ... */ }

Nicht HttpServer. Nicht ParseUrl. Das ist kein Detail. In Code-Reviews wird darauf geachtet.

Python im Kontrast:

class UserProfile:

def get_full_name(self):

...

Vor- und Nachteile

Vorteile

Platzsparend. Kein Trennzeichen nötig. Ideal, wo Bezeichner keine Leerzeichen erlauben.
Ökosystem-Verankerung. In vielen Stacks ist CamelCase Standard; das erhöht Wiedererkennung und Tool-Unterstützung.
Barrierefreiere Hashtags. Klare Wortgrenzen für Screenreader.

Nachteile

SEO-Pfadstruktur. Für URLs ungeeignet. Google empfiehlt Bindestriche und warnt vor Case-Sensitivität.
Internationalisierung. Fallstricke bei Case-Konvertierungen ohne Unicode-Bewusstsein (Türkisch, Griechisch, Deutsch).
Lesbarkeit bei langen Identifiern. getUserDataByOrganizationIdFromCache verlangt mehr Augenarbeit als get_user_data_by_organization_id_from_cache. Hier streiten sich auch die Studien.

Entscheidungshilfe: Wann CamelCase, wann nicht?

Ja, CamelCase, wenn …

Sie Bezeichner in Sprachen oder Frameworks benennen, die CamelCase als Standard vorgeben (Swift, DOM/JS, .NET, Go).
Sie Hashtags barriereärmer machen möchten.
Sie Markennamen schreiben, deren Styleguide es so vorgibt (YouTube, iPhone).

Nein, kein CamelCase, wenn …

Sie URLs oder Slugs für SEO erstellen. Hier gilt: kebab-case, Kleinschreibung.
Ihr Code-Ökosystem snake_case bevorzugt (Python-Funktionen und -Variablen).
Sie Case-Konvertierungen für nicht-englische Sprachen ohne Unicode-Bibliothek implementieren würden.

Typische Fehler

CamelCase in URLs. Schlechtere Scannbarkeit, Duplikat-Risiko, SEO-Nachteile. Lösung: kebab-Slugs in Kleinbuchstaben. Bei Migration: 301-Redirects und Canonicals.
Uneinheitliche API-Feldnamen. Kognitive Last, höhere Fehlerrate bei (De-)Serialisierung. Lösung: einheitlichen Stil im API-Styleguide festlegen, Naming-Policies nutzen.
Naives Case-Mapping. Bricht bei İ/ı, ß/ẞ, Σ/σ/ς. Lösung: Unicode-konforme Funktionen und Testdaten mit Sprachvarianten.
Verwechslung von Konventionen. Klassen in snake_case, Variablen in PascalCase. Lösung: offizielle Guides befolgen (Swift, .NET, Python, Go), Linter aktivieren.

Vergleichsübersicht

lowerCamelCase   → pageTitle, getUserData

UpperCamelCase   → PageTitle, GetUserData  (PascalCase)

snake_case       → page_title, get_user_data

kebab-case       → page-title, get-user-data  (SEO-URLs)

SCREAMING_SNAKE  → PAGE_TITLE                (Konstanten)

Was bleibt

CamelCase ist in vielen Sprachen und Ökosystemen de-facto-Standard. In Swift, .NET-APIs, DOM-Eigenschaften und Go-MixedCaps gibt es nichts zu diskutieren, nur einzuhalten. In Python gilt anderes, in URLs gilt anderes, in der Unicode-Welt gilt sowieso anderes.

Die eigentliche Kompetenz besteht nicht darin, CamelCase zu beherrschen. Sondern zu wissen, wann es das richtige Werkzeug ist und wann nicht. Wer in URL-Slugs camelCase schreibt, weil es im Code so gut funktioniert hat, baut sich Stolpersteine ein, die jahrelang stehen.

Eine Notation ist nie nur eine Notation. Sie ist ein Versprechen an alle, die nach Ihnen den Code lesen, die API integrieren, den Hashtag hören oder die URL aufrufen.

Welche Schreibweise in Ihrem Projekt heute noch ungeklärt ist und wer den Preis dafür zahlt, wenn sie es bleibt?

CamelCase