camelCase, snake_case, kebab-case: Spickzettel für Namenskonventionen
Hier die Kurzfassung. Typen und Klassen stehen in fast jeder Sprache in PascalCase. Variablen und Funktionen schreibst du in JavaScript, Java, C#, Kotlin und Swift in camelCase, in Python, Ruby und Rust dagegen in snake_case. Konstanten stehen in den meisten Sprachen in SCREAMING_SNAKE_CASE; die Ausnahmen sind Go, Swift, C# und C++ im Google-Stil. Alles, was in einer URL, einer CSS-Datei oder einem Paketnamen landet, ist meist kleingeschriebenes kebab-case, und Umgebungsvariablen stehen in Großbuchstaben mit Unterstrichen.
Das ist das Muster. Über die Details wird in Code-Reviews gestritten, deshalb hält sich dieser Spickzettel an das, was der offizielle oder am weitesten verbreitete Styleguide der jeweiligen Sprache tatsächlich sagt, und nennt für jede Sprache die Quelle.
camelCase, snake_case, kebab-case: die fünf Stile und ihre Alternativnamen
- camelCase (
orderTotal): erstes Wort klein, jedes weitere Wort mit großem Anfangsbuchstaben. Auch lowerCamelCase genannt; PEP 8 nennt es mixedCase. - PascalCase (
OrderTotal): jedes Wort mit großem Anfangsbuchstaben. Auch UpperCamelCase, CapWords (PEP 8) oder StudlyCaps (PSR-1 von PHP). - snake_case (
order_total): kleingeschriebene Wörter, mit Unterstrichen verbunden. - SCREAMING_SNAKE_CASE (
ORDER_TOTAL): Wörter in Großbuchstaben, mit Unterstrichen verbunden. Googles JavaScript-Styleguide nennt es CONSTANT_CASE, sein Java-Styleguide UPPER_SNAKE_CASE. - kebab-case (
order-total): kleingeschriebene Wörter, mit Bindestrichen verbunden. Die meisten Sprachen können es nicht für Bezeichner verwenden, weil der Bindestrich ein Minuszeichen ist.
Um einen Namen von einem Stil in einen anderen umzuwandeln, füge ihn in unseren Case-Konverter ein. Er trennt an Leerzeichen, Unterstrichen, Bindestrichen und vorhandenen Großbuchstaben, sodass sich order_total, order-total und OrderTotal sauber ineinander umwandeln lassen. Nimm aber immer nur einen Namen auf einmal: Er behandelt alles im Feld als einen einzigen Bezeichner.
Spickzettel: Namenskonventionen nach Sprache
| Sprache | Variablen und Funktionen | Klassen und Typen | Konstanten | Quelle |
|---|---|---|---|---|
| JavaScript, TypeScript | camelCase | PascalCase | CONSTANT_CASE für Werte auf Modulebene, die sich nie ändern | Google-Styleguides für JavaScript und TypeScript |
| Java | camelCase | PascalCase | UPPER_SNAKE_CASE für tief unveränderliche static final-Felder | Google Java Style Guide |
| Kotlin | camelCase | PascalCase | SCREAMING_SNAKE_CASE für const und tief unveränderliche Werte auf oberster Ebene oder in Objekten | Kotlin Coding Conventions |
| C# | camelCase für lokale Variablen und Parameter, _camelCase für private Felder, PascalCase für Methoden und öffentliche Member | PascalCase, mit dem Präfix I für Interfaces (IWorkerQueue) | PascalCase | .NET-Dokumentation von Microsoft |
| Swift | camelCase | PascalCase | camelCase | Swift API Design Guidelines |
| Go | camelCase, wenn nicht exportiert, PascalCase, wenn exportiert | Dieselbe Regel | Ebenfalls MixedCaps (MaxPacketSize) | Effective Go, Google Go Style |
| Python | snake_case | PascalCase (CapWords) | UPPER_SNAKE_CASE | PEP 8 |
| Ruby | snake_case | PascalCase | SCREAMING_SNAKE_CASE | Ruby Style Guide |
| Rust | snake_case | PascalCase (UpperCamelCase) | SCREAMING_SNAKE_CASE | Rust API Guidelines (RFC 430) |
| PHP | camelCase für Methoden; Eigenschaften bleiben dir überlassen | PascalCase (StudlyCaps) | UPPER_SNAKE_CASE für Klassenkonstanten | PSR-1 |
| C++ | snake_case für Variablen, PascalCase für Funktionen | PascalCase | kDaysInAWeek | Google C++ Style Guide (einer von mehreren) |
Ein paar Zeilen brauchen eine Fußnote. In Go ist der erste Buchstabe überhaupt keine Stilfrage, sondern die Sichtbarkeitsregel. Area wird aus seinem Paket exportiert, area nicht, und der Compiler setzt das durch. C++ hat keine sprachweite Konvention; die Standardbibliothek selbst verwendet snake_case (std::unordered_map, push_back), also betrachte die Google-Zeile als eine gut dokumentierte Option, nicht als die Regel.
Rust ist beim Stil ungewöhnlich streng. Der Compiler warnt schon ab Werk: Schreibst du fn GetUser() oder struct user_account, schlägt rustc get_user und UserAccount vor, bevor überhaupt ein Linter gelaufen ist.
Datei-, Modul- und Paketnamen
- Java: Eine öffentliche Top-Level-Klasse muss in einer Datei stehen, die genau ihren Namen trägt, Großbuchstaben inklusive.
OrderServicegehört inOrderService.java, und javac lehnt alles andere ab. - Kotlin: Eine Datei mit einer einzigen Klasse wird nach dieser Klasse benannt. Andere Dateien bekommen einen beschreibenden Namen in UpperCamelCase, etwa
ProcessDeclarations.kt. - Python: Module bekommen kurze, durchgehend kleingeschriebene Namen, mit Unterstrichen, wenn das die Lesbarkeit verbessert. Pakete sollten ebenfalls kurz und kleingeschrieben sein, und PEP 8 rät dort von Unterstrichen ab.
- Ruby: Dateien in snake_case, benannt nach der Klasse darin, also steht
HelloWorldinhello_world.rb. - Go: Paketnamen sind kleingeschriebene Einzelwörter ohne Unterstriche oder mixedCaps:
base64, nichtencoding_base64oderencodingBase64. - JavaScript und TypeScript: keine einheitliche Regel. Googles JavaScript-Styleguide will durchgehend kleingeschriebene Dateinamen mit Unterstrichen oder Bindestrichen, und sein TypeScript-Styleguide verwendet snake_case. Laut dem Styleguide von Airbnb soll ein Dateiname zu seinem Default-Export passen, also steht eine Klasse
CheckBoxinCheckBox.js. Entscheide dich pro Projekt für eine Variante und schreib sie auf. - npm-Pakete: Neue Paketnamen dürfen überhaupt keine Großbuchstaben enthalten.
Jenseits des Quellcodes: Umgebungsvariablen, CSS, HTML, URLs, JSON und SQL
| Wo | Konvention | Beispiel | Warum |
|---|---|---|---|
| Umgebungsvariablen | SCREAMING_SNAKE_CASE | DATABASE_URL | Passt zu Systemvariablen wie PATH und HOME. Unter Linux und macOS wird bei den Namen zwischen Groß- und Kleinschreibung unterschieden, unter Windows nicht. |
| CSS-Eigenschaften | kebab-case | background-color | Von der Sprache vorgegeben. |
| CSS Custom Properties | kebab-case nach zwei Bindestrichen | --brand-color | Groß- und Kleinschreibung zählt, --Brand-Color wäre also eine andere Eigenschaft. |
| CSS-Klassennamen | kebab-case, oft mit BEM | card__title--large | Liest sich wie die Eigenschaften drumherum. |
| CSS aus JavaScript | camelCase | el.style.backgroundColor | Das Style-Objekt stellt die Eigenschaftsnamen in camelCase bereit. |
| HTML-Data-Attribute | kebab-case | data-index-number | In JavaScript als dataset.indexNumber ausgelesen. |
| URL-Pfade | kleingeschriebenes kebab-case | /blog/developer-case-styles | Google empfiehlt Bindestriche statt Unterstrichen und behandelt /APPLE und /apple als verschiedene URLs. |
| JSON-Schlüssel | Kein Standard | userId oder user_id | Nach dem wichtigsten Abnehmer richten und an der Schnittstelle umwandeln. |
| SQL-Tabellen und -Spalten | kleingeschriebenes snake_case | order_items | Funktioniert in jeder großen Datenbank ohne Anführungszeichen. |
Eine Besonderheit bei Umgebungsvariablen: Laut POSIX verwenden die Standard-Dienstprogramme Namen in Großbuchstaben, und Namen mit Kleinbuchstaben sind für Anwendungen reserviert, sodass ein kleingeschriebener Name nie mit einem Standardnamen kollidieren kann. Großbuchstaben sind trotzdem die etablierte Gewohnheit, deshalb würden wir dabei bleiben und Kollisionen stattdessen mit einem eindeutigen Präfix (MYAPP_TIMEOUT) vermeiden.
Die Zeilen zu CSS und SQL haben jeweils einen eigenen Beitrag: Für Klassennamen siehe CSS-Benennung und BEM, und warum Datenbanken dich zu Kleinbuchstaben drängen, erklärt SQL-Namenskonventionen.
Akronyme: Wo sich die Styleguides uneinig sind
Bei userName sind sich alle Styleguides einig. Bei userID gehen die Meinungen auseinander. Googles Styleguides für JavaScript und Java schreiben Akronyme wie gewöhnliche Wörter klein (xmlHttpRequest, customerId). Go hält jedes Akronym durchgehend groß oder durchgehend klein (ServeHTTP, appID). Microsofts .NET-Richtlinien schreiben bei Akronymen aus zwei Buchstaben beide groß (IOStream), bei längeren nur den ersten (HtmlTag). Rust behandelt sie als Wörter (Uuid), und PEP 8 zieht HTTPServerError der Variante HttpServerError vor. Einen direkten Vergleich der Optionen findest du in camelCase vs. PascalCase.
So entscheidest du, wenn du unsicher bist
- Prüfe, ob die Plattform für dich entscheidet. CSS-Eigenschaftsnamen, Java-Dateinamen, exportierte Namen in Go und React-Komponentennamen (die mit einem Großbuchstaben beginnen müssen) sind keine Stilfrage.
- Folge dem offiziellen Styleguide der Sprache. Neuer Code sollte aussehen wie die Standardbibliothek, neben der er steht.
- Pass dich dem bestehenden Projekt an. PEP 8 sagt es ganz klar: Konsistenz innerhalb eines Projekts ist wichtiger als Konsistenz mit dem Styleguide.
- Lass einen Linter daran denken. Die ESLint-Regel
camelcase, dieN-Regeln von Ruff für Python und die eingebauten Warnungen von rustc fangen Ausrutscher ab, bevor ein Reviewer es tun muss. - Wandle einmal an der Schnittstelle um. Trifft JSON in snake_case auf JavaScript in camelCase, benenne die Schlüssel in einer einzigen Serialisierungsschicht um, statt beide Stile durch die ganze Codebasis sickern zu lassen.
