Benennungskonventionen: camelCase vs snake_case vs kebab-case vs PascalCase

Phil Karlton sagt, dass es in der Informatik nur zwei schwierige Dinge gibt: Cache-Unwirksammachung und Dinge benennen. Es ist schon schwer genug, gute Worte zu wählen; dann muß man auch entscheiden, wie man sich ihnen anschließt. userId, user_id, UserId, user-id und USER_ID beschreiben alle dasselbe Konzept, und jedes ist irgendwo richtig. Dieser Leitfaden erklärt die wichtigsten Konventionen, wo jede erwartet wird und wie man mit den peinlichen Fällen Akronymen, Zahlen und Grenzen zwischen Systemen umgeht.

Die wichtigsten Konventionen

Name	Beispiel	Typische Verwendung
KammelKase	getUserById	JavaScript/TypeScript-Variablen und -Funktionen, Java-Methoden, JSON-Felder
Das ist PascalCase.	UserProfile	Klassen, Typen, React-Komponenten, C#-Methoden
Schlange-Fall	get_user_by_id	Python, Ruby, Rust Funktionen, SQL Spalten
Das ist ein Schreckensfall.	MAX_RETRIES	Konstanten, Umweltvariablen
Kebab-Kase	user-profile	URLs, CSS-Klassen, HTML-Attribute, Dateinamen, CLI-Flaggen
Zuggehäuse	Content-Type	HTTP-Header
Punkt.Fall	app.server.port	Konfigurationsschlüssel, Java-Pakete

Ein [case-converter] ((/tools/case-converter) kann jeden Namen zwischen all diesen auf einmal übersetzen, was praktisch ist, wenn Daten zwischen Schichten verschoben werden.

Konventionen nach Sprache und Kontext

JavaScript und TypeScript

• Variablen, Funktionen und Objekteigenschaften: camelCase.
• Klassen, Schnittstellen, Typen-Aliase, Enums und React-Komponenten: PascalCase. React erfordert, dass Komponenten mit einem Großbuchstaben beginnen, damit JSX sie von HTML-Elementen unterscheiden kann.
• Wahre Konstanten (Konfiguration, die sich nie ändert): SCREAMING_SNAKE_CASE, obwohl viele Codebasen camelCase für const-Variablen verwenden.
• Dateinamen: häufig kebab-case (user-profile.tsx) oder PascalCase für Komponentendateien. Wählen Sie die erste; Mischbuchstaben in den Dateinamen verursachen Probleme bei Groß- und Kleinbuchstaben-unempfindlichen Dateisystemen.

Python

PEP 8 ist explizit: snake_case für Funktionen, Variablen und Module, PascalCase (die PEP 8 CapWords nennt) für Klassen und SCREAMING_SNAKE_CASE für Modulkonstanten. Eine unterste Zeile zeigt "intern": _cache.

Geht .

Go verwendet camelCase und PascalCase, und Fallzeichen hat Bedeutung: Kennungen, die mit einem Großbuchstaben beginnen, werden aus dem Paket exportiert, Kleinbuchstaben sind privat. Der Go-Stil hält die Akronyme groß geschrieben: userID, HTTPServer, parseURL.

Java und C#

Beide verwenden PascalCase für Klassen und camelCase für lokale Variablen. Java verwendet camelCase für Methoden; C# verwendet PascalCase für Methoden und öffentliche Eigenschaften.

Rost

snake_case für Funktionen, Variablen und Module; PascalCase für Typen und Eigenschaften; SCREAMING_SNAKE_CASE für Konstanten und Statik. Der Compiler warnt, wenn Sie abweichen.

SQL-Datenbanken

snake_case ist die sichere Wahl für Tabellen und Spalten. In PostgreSQL werden nicht zitierte Kennungen in Kleinbuchstaben gefaltet, so dass eine Spalte, die als "userId" erstellt wurde, für immer zitiert werden muss, während user_id überall funktioniert. Ob die Tabellennamen in Singular (user) oder Plural (users) sind, hängt von der Präferenz des Teams ab; Konsistenz ist wichtiger als die Wahl.

CSS und HTML

CSS-Eigenschaften sind kebab-case (background-color), so dass Klassennamen normalerweise folgen: .card-header. Methoden wie BEM ergänzen die Struktur: .card__title--active. HTML-Attribute, einschließlich data-*-Attribute, sind groß- und kleinbuchstabenunempfindlich; JavaScript legt data-user-id als element.dataset.userId offen.

URLs

Für Wege mit kleinerem kebab-case verwenden: /blog/compress-image-to-100kb. Google behandelt Bindestricke als Worttrennzeichen, unterstreicht aber als Verbinder, also sind Bindestricke besser für SEO. Vermeiden Sie Großbuchstaben in URLs; viele Server behandeln Pfade als großbuchstabenempfindlich und verursachen Probleme mit doppelten Inhalten.

Umweltvariablen

SCREAMING_SNAKE_CASE, DATABASE_URL, STRIPE_SECRET_KEY. Shell- und Container-Plattformen erwarten dies, und einige erlauben überhaupt keine Bindestrichzeichen in Variablennamen.

Abkürzungen und Initialismen

Hier streiten sich die Teams am meisten. Soll es parseHTTPResponse oder parseHttpResponse sein? userID oder userId?

• Akronyme als Wörter behandeln (parseHttpResponse, userId, XmlParser): empfohlen von Microsofts .NET-Richtlinien für Akronymen mit mehr als zwei Buchstaben, von Googles Java- und JavaScript-Style-Guides und von vielen TypeScript-Codebasen. Es vermeidet unlesbare Läufe wie HTTPSURLConnection und konvertiert sauber zwischen den Fällen parseHttpResponse wird automatisch parse_http_response.
• Keep Akronyms in Großbuchstaben (parseHTTPResponse, userID): Standard in Go und üblich in älteren Java- und Objective-C-Codes.

Automatische Konverter teilen parseHTTPResponse als Parse / HTTP / Response auf, was funktioniert, aber HTTPSURLConnection ist zweideutig. Wenn Sie den Stil kontrollieren, ist es robuster, Akronymen als Wörter zu behandeln.

Zahlen in Namen

Die Zahlen müssen dem Wort zugeordnet sein: version2, utf8Decoder, base64_encode, h1-title. Vermeide es, Identifikatoren mit Ziffern zu starten; die meisten Sprachen verbieten es, und CSS-Klassen, die mit Ziffern beginnen, müssen entkommen.

Grenzüberschreitungen: API und Datenbanken

Echte Systeme mischen Konventionen. Ein Python-Backend mit snake_case dient einem JavaScript-Frontend, das camelCase erwartet, unterstützt von einer SQL-Datenbank mit snake_case-Spalten. Die Auswahlmöglichkeiten

1. Verwenden Sie eine Konvention auf dem Draht. Entscheiden Sie, ob JSON camelCase (die häufigste Wahl für öffentliche APIs, die mit JavaScript übereinstimmen) oder snake_case (in Python und Ruby-Ökosystemen üblich und von APIs wie Stripe und GitHub verwendet) verwendet. Dokumenten und überall anwenden.
2. Konvertieren an den Rändern. Serialisierungsbibliotheken können automatisch konvertieren: Pydantic Alias-Generatoren, Jackson PropertyNamingStrategies oder ORM Spalten-Mapping. Innerhalb jeder Schicht bleibt der Code idiomatisch.
3. ** Nicht in einer Nutzlast mischen. ** { "userId": 1, "created_at": "..." } ist das Schlimmste aus beiden Welten.

Bei der Generierung von TypeScript-Typen aus JSON , die in unserem JSON-to-TypeScript-Leitfaden enthalten sind, behalten Sie Eigenschaftsnamen genau so, wie sie auf dem Draht erscheinen, und konvertieren Sie bei Bedarf in eine Mapping-Schicht.

Gute Worte wählen

Der Fall-Stil ist der leichte Teil. Ein paar Regeln für die Worte selbst:

• ** Seien Sie spezifisch.** data, info und item sagen nichts. invoiceLines sagt viel aus.
• ** Verwenden Sie Verben für Funktionen und Substantive für Werte.** calculateTotal() gibt total zurück.
• Nennen Sie Booleaner als Fragen. isActive, hasAccess, shouldRetry.
• Einheiten enthalten. timeoutMs, maxSizeBytes, durationSeconds verhindern eine ganze Klasse von Fehlern.
• Vermeiden Sie Abkürzungen, es sei denn, sie sind allgemein (id, url, html). usrCnt spart vier Zeichen und kostet jedem Leser einen Moment.
• Die Domänensprache passen. Wenn das Unternehmen "Abonnement" sagt, nennen Sie es nicht plan im Code.

Durchsetzung von Übereinkommen

Schreiben Sie die Konventionen auf und lassen Sie sie von Tools durchsetzen: ESLints @typescript-eslint/naming-convention-Regel, Pylint und Ruff für Python, golint und go vet, Rust's integrierte Lints und Stylelints für CSS-Klassenmuster. Automatisierte Kontrollen beenden Debatten bei der Code-Überprüfung und halten große Codebasen konsistent.

Zusammenfassung

Verwenden Sie camelCase für JavaScript-Werte, PascalCase für Typen und Komponenten, snake_case für Python, Rust und SQL, kebab-case für URLs, CSS und Dateinamen und SCREAMING_SNAKE_CASE für Konstanten und Umweltvariablen. Behandeln Sie Akronymen wie Wörter, wenn Sie können, halten Sie Einheiten in Namen, wählen Sie eine Konvention für jede API und lassen Sie Linters die Regeln durchsetzen, damit sich Menschen auf die Auswahl guter Wörter konzentrieren können.