Schreibweisen und Namenskonventionen erklärt
Namen in Code, Dateien, URLs und Überschriften folgen Konventionen, die sich von Sprache zu Sprache und Format zu Format unterscheiden. Diese Anleitung zeigt die gängigen Schreibweisen, wo welche erwartet wird, und die Details, über die man oft stolpert: Abkürzungen, Zahlen, Überschriften und Buchstaben jenseits des Englischen.
Die gängigen Schreibweisen
| Schreibweise | Beispiel | Aufbau |
|---|---|---|
| camelCase | orderTotal | Erstes Wort klein, weitere Wörter mit großem Anfangsbuchstaben, ohne Trennzeichen |
| PascalCase | OrderTotal | Jedes Wort mit großem Anfangsbuchstaben, ohne Trennzeichen |
| snake_case | order_total | Kleinbuchstaben, Wörter mit _ verbunden |
| CONSTANT_CASE | ORDER_TOTAL | Großbuchstaben, Wörter mit _ verbunden |
| kebab-case | order-total | Kleinbuchstaben, Wörter mit - verbunden |
| dot.case | order.total | Kleinbuchstaben, Wörter mit . verbunden |
| Title Case | Order Total | Wörter durch Leerzeichen getrennt, jedes mit großem Anfangsbuchstaben |
| Sentence case | Order total | Nur das erste Wort mit großem Anfangsbuchstaben |
camelCase heißt manchmal auch lower camel case und PascalCase upper camel case. CONSTANT_CASE ist auch als screaming snake case bekannt.
Welche Schreibweise jede Sprache und jedes Format erwartet
Die meisten Ökosysteme haben sich längst auf eine Konvention geeinigt, und wer ihr folgt, macht Code für alle lesbarer, die dieses Ökosystem kennen:
| Wo | Übliche Konvention |
|---|---|
| JavaScript, TypeScript, Java | camelCase für Variablen und Funktionen, PascalCase für Klassen, CONSTANT_CASE für feste Konstanten |
| Python (PEP 8) | snake_case für Funktionen und Variablen, PascalCase für Klassen, CONSTANT_CASE für Konstanten |
| C# | PascalCase für Typen, Methoden und öffentliche Member, camelCase für lokale Variablen und Parameter |
| Go | PascalCase exportiert einen Namen aus seinem Paket, camelCase hält ihn privat |
| Ruby, Rust | snake_case für Methoden und Variablen, PascalCase für Typen |
| CSS und HTML | kebab-case für Eigenschaften, Klassennamen und data-Attribute |
| URLs | kebab-case; Google empfiehlt Bindestriche statt Unterstriche zwischen Wörtern |
| SQL-Tabellen und -Spalten | snake_case, weil viele Datenbanken Namen ohne Anführungszeichen auf eine Schreibweise vereinheitlichen |
| Umgebungsvariablen | CONSTANT_CASE, etwa DATABASE_URL |
| Konfigurationsschlüssel | dot.case für verschachtelte Einstellungen, etwa server.port |
| JSON-APIs | Keine einheitliche Regel: viele nutzen camelCase, andere snake_case; richten Sie sich nach der API, mit der Sie arbeiten |
kebab-case ist in den meisten Programmiersprachen für Variablennamen nicht möglich, weil der Bindestrich als Minuszeichen gelesen wird: order-total bedeutet order minus total.
Abkürzungen und Zahlen
Bei Abkürzungen gehen die Konventionen am weitesten auseinander. Die eine Schule lässt sie in Großbuchstaben (userID, parseHTML), die andere behandelt sie wie gewöhnliche Wörter (userId, parseHtml). Die Java- und JavaScript-Styleguides von Google folgen dem zweiten Ansatz, der Wortgrenzen deutlich hält, wenn Abkürzungen aufeinandertreffen: XmlHttpRequest lässt sich leichter zerlegen als XMLHTTPRequest. Die .NET-Richtlinien von Microsoft schreiben zweibuchstabige Abkürzungen groß (IOStream) und bei längeren nur den ersten Buchstaben (HtmlButton). Die Browser-API XMLHttpRequest mischt beides und wird deshalb oft als warnendes Beispiel zitiert.
Zahlen haben keine Groß- und Kleinschreibung, daher kann ein Konverter nicht erkennen, ob utf8Decoder „utf8 decoder“ oder „utf 8 decoder“ meint. Konverter hängen eine Zahl meist an das vorangehende Wort. Legen Sie sich auf eine Schreibung fest und verwenden Sie sie überall.
Title Case und Sentence case in Überschriften
Bei englischen Überschriften schreiben Styleguides nicht jedes Wort gleich groß. Der AP- und der Chicago-Stil lassen kurze Artikel, Konjunktionen und Präpositionen klein, außer am Anfang oder Ende („The Lord of the Rings“), und unterscheiden sich in der genauen Liste. Viele Leitfäden für Oberflächen und Dokumentation, darunter die Entwicklerdokumentations-Leitfäden von Microsoft und Google, verwenden stattdessen Sentence case („Change your password“), das sich einheitlicher anwenden lässt und weniger förmlich wirkt.
Das Title Case des LeedyBox-Konverters schreibt jedes Wort groß. Für Beschriftungen und variablenartige Namen passt das, für eine Überschrift im Zeitungsstil aber nicht: Setzen Sie die kurzen Wörter danach von Hand in Kleinbuchstaben.
Umwandlungen verlieren Informationen
Jede Umwandlung zerlegt einen Namen zuerst in Wörter, mit Großbuchstaben und Trennzeichen als Hinweisen, und fügt die Wörter dann in der neuen Schreibweise zusammen. Was die Zielschreibweise nicht ausdrücken kann, geht verloren: parseHTML wird zu parse_html, und die Rückumwandlung ergibt parseHtml. Auch Satzzeichen fallen weg, sodass „don't“ zu zwei Wörtern wird.
Behandeln Sie deshalb eine Schreibweise als maßgebliche Quelle. Verwendet eine Datenbank snake_case und der Code camelCase, wandeln Sie an der Grenze jedes Mal in dieselbe Richtung um, statt Namen in beiden Formen zu speichern.
Schlüssel an einer API-Grenze umbenennen
Wenn ein Frontend in camelCase mit einem Backend in snake_case spricht, können die meisten Serialisierungsbibliotheken die Namen automatisch zuordnen, sodass die Daten nie von Hand umbenannt werden. Ein JSON-Dokument einmalig umzuwandeln, etwa Testdaten oder eine Beispielantwort, ist eine andere Aufgabe, und der Modus „JSON-Schlüssel“ des Schreibweisen-Konverters erledigt sie, ohne die Werte anzutasten.
Achten Sie auf Kollisionen: user_name und userName werden in beiden Schreibweisen zum selben Schlüssel, und einer würde den anderen überschreiben. Führende Symbole wie _id oder $ref haben oft eine Bedeutung für eine bestimmte Datenbank oder ein Schema; prüfen Sie also, ob sie überhaupt umbenannt werden dürfen.
Groß- und Kleinschreibung jenseits des Englischen
Die Regeln für Groß- und Kleinschreibung sind nicht in jeder Sprache gleich. Das deutsche ß wird in Großbuchstaben zu SS, das Wort wird also länger. Das Türkische hat ein i mit und ein ı ohne Punkt: Die Großbuchstaben-Paare sind i → İ und ı → I, während die Standardregel der meisten Programmiersprachen i zu I macht. toUpperCase() in JavaScript nutzt die Standardregel; toLocaleUpperCase('tr') wendet die türkische an. Koreanisch, Chinesisch und Japanisch kennen gar keine Groß- und Kleinschreibung, daher ändern sich nur die Trennzeichen zwischen den Wörtern.
Auch bei Dateinamen kann die Schreibung zählen. Windows und standardmäßig macOS behandeln Readme.md und README.md als dieselbe Datei, Linux dagegen als zwei. Eine Umbenennung, die nur die Groß- und Kleinschreibung ändert, kann daher auf einem System unbemerkt bleiben und auf einem anderen Links oder Imports zerstören.
Häufig gestellte Fragen
Ist camelCase oder snake_case besser?
Keines ist grundsätzlich besser. Verwenden Sie die Konvention der Sprache, des Frameworks oder der API, mit der Sie arbeiten; Einheitlichkeit innerhalb einer Codebasis zählt mehr als die Wahl selbst.
Sollten URLs Bindestriche oder Unterstriche verwenden?
Bindestriche. Googles Hinweise zu URLs empfehlen Bindestriche zwischen Wörtern, und kebab-case-Slugs wie /case-converter/ sind im Web üblich.
Warum bemerkt Git nicht, dass ich nur die Groß- und Kleinschreibung eines Dateinamens geändert habe?
Auf einem Dateisystem ohne Unterscheidung von Groß- und Kleinschreibung behandelt Git den alten und den neuen Namen oft als dieselbe Datei. Benennen Sie die Datei mit git mv um, zum Beispiel über einen Zwischennamen, damit die Änderung für Systeme erfasst wird, auf denen die Schreibung zählt.
Wie schreibe ich einen Markennamen wie iPhone oder eBay in camelCase?
Konverter trennen an Großbuchstaben, daher ergeben solche Namen getrennte Wörter. Im Code ist es meist klarer, die Marke als ein Wort zu behandeln (iphoneModel) und ihre offizielle Schreibweise nur in Texten für Menschen zu verwenden.