camelCase vs snake_case vs kebab-case: 2026-gids voor naamgevingsconventies
userID of userId? user_profile of userProfile? URL’s met - of _? Dat zijn de kleine vragen die een PR-review vijf keer per dag laten ontsporen. Het antwoord is geen “persoonlijke voorkeur” — elke mainstream taal en elke webstandaard heeft een vaste regel, en zodra je ze op één pagina ziet, valt de ruis weg.
Deze gids behandelt de zes cases die je in code daadwerkelijk tegenkomt (camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, dot.case / path/case / Header-Case), een beslissingsmatrix voor zeven talen, het parseUrl-vs-parseURL-acroniemdebat met echte GitHub-data, de SEO-argumenten voor kebab-case-URL’s, en de zes valkuilen die toeslaan zodra je tussen cases automatisch converteert. Wil je alle 15 case-uitvoeren voor een willekeurige string in één keer zien, dan rendert de Case converter ze live in je browser.
De zes cases in één oogopslag
Voor we beginnen met vergelijken, hier is de spiekbrief. Print hem, plak hem in je teamwiki, of houd hem gewoon open in een tab.
| Case-stijl | Voorbeeld | Typisch gebruik | Oorsprong / popularisator |
|---|---|---|---|
| camelCase | userProfileImage | JS-, TS-, Java-, Swift-variabelen & methoden | Smalltalk → Java |
| PascalCase | UserProfileImage | Klassen, React-/Vue-componenten, TS-types | Pascal-taal |
| snake_case | user_profile_image | Python, Ruby, Rust, SQL-kolommen | C / vroeg Unix |
| kebab-case | user-profile-image | CSS-klassen, URL-slugs, HTML-attributen | Lisp / modern web |
| CONSTANT_CASE | USER_PROFILE_IMAGE | Env-variabelen, top-level constanten, macro’s | C-macro’s / Unix-env |
| dot.case | user.profile.image | Java-packages, MongoDB-paden, TOML-sleutels | Namespace-conventie |
| path/case | user/profile/image | URL-paden, bestandssysteem, Git-refs | Unix-paden |
| Header-Case | User-Profile-Image | HTTP/1.1 header-namen (canoniek) | RFC 2616 |
Acht rijen voor zes “echte” cases — dot.case, path/case en Header-Case delen dezelfde onderliggende tokenisatie met verschillende scheidingstekens, en daarom behandelen de meeste case-libraries ze als één familie.
Elke case van dichtbij
camelCase: de standaard van JS/Java
camelCase was het idee van Smalltalk, maar Java was de taal die hem aan de rest van de industrie heeft geëxporteerd. Sun’s Java-codeconventies uit 1995 maakten firstName, getUserProfile en xmlParser de standaardspelling, en elke taal die er Java-achtig uit wilde zien — JavaScript, ActionScript, Swift, Kotlin, Dart — erfde dezelfde vorm.
Regel: het eerste woord in kleine letters, elk volgend woord met hoofdletter, scheidingsteken volledig weglaten. Geen underscores, geen koppeltekens, geen spaties. De naam “camelCase” komt van de hobbelige omtrek van hoofdletters die door een zee van kleine letters omhoogsteken.
Twee randgevallen waar mensen het mis hebben: merknamen die met een kleine letter beginnen (iPhone, eBay, iOS) — als zo’n naam in code voorkomt, forceer dan niet de hoofdletter op de i; spel hem zoals het merk dat doet en accepteer de iets vreemd ogende identifier. En acroniemen — die behandelen we hieronder in detail.
PascalCase: klassen en componenten
PascalCase is gewoon camelCase met de eerste letter als hoofdletter. Sommige stijlgidsen noemen het daarom letterlijk “UpperCamelCase”. De Pascal-taal gebruikte het in de jaren 1970 en de naam bleef hangen.
Waar hij leeft: klassennamen in elke OO-taal uit de C-familie (Java, C#, C++, Kotlin, Swift, TypeScript), namen van React-/Vue-/Angular-componenten, TypeScript-type-aliassen en interfaces (type UserProfile, interface AuthState), en module-/bestandsnamen in sommige ecosystemen (UserService.cs in C#).
Waarom überhaupt een aparte case voor klassen? Het is puur een visueel signaal. Wanneer je new userProfile() versus new UserProfile() leest, leest de tweede meteen als een type en de eerste als een functieaanroep die verkeerd is gegaan. Talen die value- en type-namespaces mengen, leunen op de hoofdletter om te disambigueren.
snake_case: Python, Ruby, Rust, SQL
snake_case is ouder dan de meeste mensen denken — C en het vroege Unix gebruikten namen als errno_h en fopen_s, omdat toetsenborden op PDP-11-terminals underscores makkelijk maakten en hoofdletters in Pascal-stijl pielwerk. Python heeft snake_case als officiële PEP 8-conventie overgenomen, de Ruby-community is er organisch op uitgekomen, en Rust heeft hem tot compiler-afgedwongen standaard gemaakt met een lint die klaagt als je variabele userId heet in plaats van user_id.
Regel: alles in kleine letters, woorden verbonden met underscores. user_profile_image, parse_html, max_retries.
De database-invalshoek doet ertoe en is het deel dat de meeste taalhandleidingen overslaan. Vrijwel elke SQL-ORM — SQLAlchemy, Hibernate, Sequelize, TypeORM, Active Record — gebruikt standaard snake_case-kolomnamen, ongeacht de conventie van de host-taal. De reden is portabiliteit: PostgreSQL vouwt niet-aangehaalde identifiers naar lowercase, MySQL op Linux is hoofdlettergevoelig, MySQL op macOS/Windows is hoofdletterongevoelig, en SQLite behandelt kolomnamen als ondoorzichtige strings. snake_case is de enige spelling die al die situaties overleeft zonder aanhalingstekens.
kebab-case: de keuze van het web
Het web is uitgekomen op kebab-case voor alles wat zichtbaar is voor gebruikers: CSS-klassenamen (.user-profile-image), URL-slugs (/blog/naming-conventions-guide), aangepaste HTML-attributen (data-user-id), tagnamen van Web Components (<user-card>, waarvan de spec letterlijk eist dat hij een koppelteken bevat).
De naam zelf duikt in ongeveer acht varianten in oudere docs op — “dash-case”, “spinal-case”, “lisp-case”, “skewer-case”, “hyphen-case”. Ze betekenen allemaal hetzelfde. “kebab-case” is degene die bleef hangen door een oude Stack Overflow-grap over hoe de woorden eruitzien als vlees op een spies.
Een niet-voor-de-hand-liggende regel: HTML- en CSS-klassenamen zijn in de praktijk hoofdletterongevoelig, maar de canonieke spelling is lowercase. .User-Profile werkt in de meeste browsers, maar het breekt server-side tooling die klassennamen een hash geeft, en het verwart code-reviewers. Houd het bij lowercase.
CONSTANT_CASE: env-variabelen en macro’s
CONSTANT_CASE (soms SCREAMING_SNAKE_CASE in Rust-kringen) is het universele “deze waarde verandert nooit tijdens runtime”-signaal. MAX_RETRIES, API_KEY, DEFAULT_TIMEOUT_MS. Elke taal heeft er een conventie voor, en elk CI-systeem, elke container-runtime en elke shell verwacht omgevingsvariabelen in deze case (DATABASE_URL, NODE_ENV, PATH).
Valkuil: het const-sleutelwoord van JavaScript betekent niet “gebruik CONSTANT_CASE”. const result = await fetch(url) is perfect correcte camelCase. Bewaar CONSTANT_CASE voor echte semantische constanten — waarden die in C een #define zouden krijgen, het soort waarbij de waarde tijdens runtime veranderen een bug is. MAX_RETRIES = 3 voldoet. result niet.
dot.case, path/case, Header-Case
Drie broers en zussen die dezelfde tokenizer delen met verschillende scheidingstekens.
dot.case representeert hiërarchische sleutels: Java-packages (com.example.service), MongoDB-veldpaden (user.profile.image), TOML-/INI-configuratiesleutels ([database.primary]), Lodash-methodepaden (_.get(obj, 'user.profile.image')). Wanneer je een dot.case-string leest, moet je “namespace, namespace, blad” zien.
path/case representeert letterlijke locaties: URL-paden, bestandssysteempaden, Git-refs (feature/add-auth). De keuze tussen punten en schuine strepen is betekenisvol — schuine strepen signaleren “dit is iets echts ergens”, punten signaleren “dit is een label”.
Header-Case is de HTTP/1.1-conventie: Content-Type, Access-Control-Allow-Origin, X-Forwarded-For. HTTP/1.1-headers zijn technisch hoofdletterongevoelig (RFC 2616), dus content-type werkt ook, maar elk framework, elk stuk documentatie en elke ontwikkelaar verwacht de Header-Case-spelling. HTTP/2 en HTTP/3 hebben dit veranderd — RFC 7540 §8.1.2 schrijft lowercase header-namen op de draad voor om header-compressie (HPACK) te vereenvoudigen. Voor applicatiecode blijft dit onzichtbaar omdat elke HTTP/2-client en -server het voor je normaliseert, maar inspecteer je ooit een rauwe HTTP/2-frame, dan zijn de headers volledig lowercase kebab-case.
Beslissingsmatrix voor zeven talen
De snelste manier om een naamgevingsdiscussie te beslechten is opzoeken wat de standaardbibliotheek van de taal doet. Hier is de matrix.
| Taal | Variabele | Functie | Klasse | Constante | Bestandsnaam | DB-kolom |
|---|---|---|---|---|---|---|
| Python (PEP 8) | snake_case | snake_case | PascalCase | CONSTANT_CASE | snake_case.py | snake_case |
| JavaScript/TS | camelCase | camelCase | PascalCase | CONSTANT_CASE | kebab-case.js | snake_case |
| Go | camelCase* | PascalCase** | PascalCase | mixedCase*** | snake_case.go | snake_case |
| Rust | snake_case | snake_case | PascalCase | SCREAMING_SNAKE | snake_case.rs | snake_case |
| Java | camelCase | camelCase | PascalCase | CONSTANT_CASE | PascalCase.java | snake_case |
| C# | camelCase† | PascalCase | PascalCase | PascalCase | PascalCase.cs | snake_case |
| SQL | n.v.t. | snake_case | n.v.t. | n.v.t. | n.v.t. | snake_case |
*Go: een kleine letter als eerste betekent niet-geëxporteerd (package-private); een hoofdletter als eerste betekent geëxporteerd (publiek). De compiler dwingt dit af.**Go: geëxporteerde functies zijn PascalCase (http.NewRequest); package-private functies zijn camelCase (http.parseHeader).***Go: constanten volgen dezelfde regel voor geëxporteerd/niet-geëxporteerd —MaxRetriesvoor geëxporteerd,maxRetriesvoor niet-geëxporteerd. Go vermijdt CONSTANT_CASE bewust.†C#: lokale variabelen en private velden zijn camelCase (sommige codebases prefixen velden met_:_userName); publieke properties, methoden en types zijn PascalCase.
Drie lagen die door elke taal heen lopen:
HTML en CSS: klassennamen en ID’s zijn kebab-case (<div class="user-profile-card">). Aangepaste HTML-attributen zijn kebab-case met een data--prefix (data-user-id). Inline CSS-properties zijn kebab-case (background-color); de JS-DOM-equivalenten zijn camelCase (element.style.backgroundColor).
HTTP: uitgaande header-namen zijn Header-Case voor HTTP/1.1 ('Content-Type': 'application/json') en lowercase kebab-case op de HTTP/2-draad. De meeste fetch-libraries accepteren beide spellingen en normaliseren intern.
Omgevingsvariabelen: CONSTANT_CASE overal — Node, Python, Go, Rust, Bash, Docker, Kubernetes. De conventie voor het .env-bestand is dezelfde: DATABASE_URL=postgres://....
Acroniem-behandeling: Google vs Microsoft
Dit is de allerheftigste naamgevingskwestie tijdens code review. Moet het parseUrl of parseURL zijn? userId of userID? HtmlParser of HTMLParser? XmlHttpRequest of XMLHttpRequest?
Er bestaan twee scholen, en beide hebben echte autoriteit in de praktijk.
Acroniem-als-woord behandelen (Google, Apple, moderne JS): parseUrl, userId, HtmlParser. De Google JavaScript Style Guide §5.3 raadt dit expliciet aan. Apple’s Swift API Design Guidelines doen hetzelfde. De lodash- en change-case-packages produceren deze uitvoer standaard. Het argument is round-trip-stabiliteit: parseUrl tokeniseert netjes naar parse / url, converteert naar parse_url en terug naar parseUrl zonder informatieverlies. parseURL tokeniseert naar parse / URL, converteert naar parse_u_r_l onder een naïeve tokenizer of parse_url onder een acroniem-bewuste tokenizer — maar dan kan parse_url niet beslissen of hij terug round-tript naar parseUrl of parseURL, omdat de volledig lowercase spelling het acroniem-signaal kwijt is.
Acroniem-hoofdletters bewaren (Microsoft, .NET, ouder Java): parseURL, userID, HTMLParser, XMLHttpRequest. De Microsoft .NET Naming Guidelines beperken dit tot acroniemen van 2-3 letters (IO, URL, XML) en gebruiken acroniem-als-woord voor langere (Html zou onder de strikte lezing preserve-caps zijn, maar Microsoft schrijft in de praktijk HtmlAgilityPack). De Win32 API, de .NET BCL en de meeste Java-code van vóór 2010 gaan deze weg. Het leest natuurlijker voor Engelstaligen — parseURL leest als “parse U-R-L” — ten koste van de round-trip-eigenschap.
Python’s PEP 8 raadt op papier acroniem-als-woord aan, maar de Python-standaardbibliotheek is historisch inconsistent: http.server.HTTPServer en xml.etree.ElementTree bewaren acroniemen terwijl json.JSONDecoder hetzelfde doet. Nieuwere toevoegingen (pathlib.PurePath, dataclasses) neigen naar acroniem-als-woord. De PEP 8-lijn is: volg wat de omringende code doet.
Een steekproef op GitHub’s publieke corpus begin 2026 (de BigQuery bigquery-public-data.github_repos-sample, gefilterd op TypeScript- en JavaScript-bestanden uit repo’s met 1k+ sterren) laat ongeveer een 7:3-verhouding zien van parseUrl tegenover parseURL en een 6:4-verhouding van userId tegenover userID. De acroniem-als-woord-stijl wint in JavaScript. C# blijft sterk Microsoft-stijl — parseURL domineert in C#-bestanden. Python is werkelijk verdeeld.
Beslissingsregel: (a) volg de standaardbibliotheek van de taal waarin je schrijft; (b) als de standaardbibliotheek inconsistent is, kies acroniem-als-woord voor greenfield-projecten omdat die round-tript; (c) leg de keuze vast in je linter of style-config en meng nooit beide binnen één project. De tokenizer van de Case converter volgt de acroniem-als-woord-conventie zodat hij overeenkomt met lodash en de change-case-package — plak XMLHttpRequest en je ziet xmlHttpRequest, xml_http_request, xml-http-request als de camelCase-, snake_case- en kebab-case-uitvoer.
URL-slugs: waarom kebab-case snake_case verslaat
Als je Google’s officiële Search Central-documentatie over URL-structuur leest, geeft die precies één specifieke case-aanbeveling: gebruik koppeltekens om woorden in URL’s te scheiden, gebruik geen underscores. De reden is tokenisatie. Google’s zoekindex splitst URL’s op koppeltekens maar niet op underscores. https://example.com/buy-running-shoes wordt getokeniseerd als buy, running, shoes — drie indexeerbare termen die op elk van die zoekwoorden kunnen matchen. https://example.com/buy_running_shoes wordt getokeniseerd als de enkele term buy_running_shoes, die alleen op die exacte string matcht.
Het praktische effect op rankings is klein voor gevestigde pagina’s (Google heeft andere signalen), maar reëel voor nieuwe pagina’s die in een krappe SERP concurreren. Bij een gelijke pagina rankt de kebab-case-URL hoger.
Er is een tweede reden: hoofdlettergevoeligheid. URL-paden zijn hoofdlettergevoelig op Linux-servers (wat het grootste deel van het web is). /User-Profile en /user-profile zijn twee verschillende URL’s, twee verschillende cache-entries, twee verschillende analytics-rijen. Lowercase kebab-case is de enige spelling die geen “maar het werkt op mijn Mac”-bug uitnodigt.
Een slug-recept van vier stappen dat voor elke titel werkt:
- Alles in kleine letters.
- Vervang reeksen van witruimte en interpunctie door een enkel koppelteken.
- Strip leidende en sluitende koppeltekens.
- Optioneel: stopwoorden weglaten (
a,an,the,of,for) voor kortere URL’s — doe dit alleen als je CMS de originele titel voor de paginakop bewaart.
Uitgewerkt voorbeeld: "10 Tips for Faster JavaScript: A Complete Guide" → 10-tips-faster-javascript-complete-guide. De dubbele punt en de stopwoorden (for, a) vallen weg; het resultaat is 39 tekens, makkelijk onder het sweet spot van 50-60 tekens voor SERP-weergave. Voor meer over URL-lengte en hoe die samenhangt met tekenlimieten per platform, zie de Gids teken- en woordlimieten.
De Case converter geeft je in één plak-actie de kebab-case-uitvoer voor elke titel — handig wanneer je in bulk slugs genereert voor een CMS-migratie of een sitemap.
Zes valkuilen bij conversie
Automatisch converteren tussen cases lijkt triviaal. Dat is het niet. Hier zijn de zes plekken waar het breekt.
1. Grenzen tussen cijfers en letters
Wat is file2x na een snake_case-conversie? De mainstream-conventie — lodash, change-case, PEP 8, de Case converter — behandelt elke letter-cijfer-overgang als een token-grens, dus file2x wordt file / 2 / x en snake_cased tot file_2_x. parseUTF8 wordt parse / utf / 8 en parse_utf_8.
Sommige oudere libraries (en sommige handgeschreven re.sub-snippets die je op Stack Overflow vindt) slaan deze regel over en produceren file2x → file2x of parseutf8. De mismatch komt pas naar boven wanneer je code tussen libraries migreert, en het symptoom is “de helft van mijn identifiers is hernoemd en de helft niet”. Kies een tokenizer, controleer dat hij de cijfergrensregel volgt, en blijf erbij.
2. Opeenvolgende hoofdletters
De regex voor de acroniemgrens is /([A-Z]+)([A-Z][a-z])/ — splits tussen een reeks hoofdletters en een laatste hoofdletter die een nieuw woord begint. XMLHttpRequest matcht als XML + HttpRequest, daarna Http + Request, en levert de tokens XML / Http / Request.
De terugreis is waar het misgaat: XML / Http / Request opnieuw naar PascalCase wordt XmlHttpRequest, niet XMLHttpRequest. Het acroniem is title-cased geraakt. Dat is het standaardgedrag, omdat het alternatief — onthouden welke tokens oorspronkelijk acroniemen waren — out-of-band-metadata vereist die tokenizers niet hebben. Werkt je codebase in XMLHttpRequest-stijl en draai je een project-brede rename via een acroniem-als-woord-converter, dan herschrijf je elk acroniem zonder dat je het merkt. Test eerst op een branch, of gebruik een tokenizer waarmee je acroniemen expliciet kunt markeren.
3. Unicode en locale-bewuste case-mapping
'I'.toLowerCase() in JavaScript geeft meestal 'i' terug. Voer dezelfde aanroep uit met de Turkse locale actief en het resultaat is 'ı' (puntloze i, U+0131), omdat het Turks twee verschillende i-letters heeft en de kleine letter van hoofdletter-I de puntloze is. Deze bug is in talloze internationalisatie-roll-outs meegekomen — login-formulieren die de gebruikersnaam in hoofdletters zetten voor vergelijking sluiten elke Turks-gelokaliseerde gebruiker met de naam İrem zonder zichtbare foutmelding buiten.
Nog twee landmijnen: het Duitse ß.toUpperCase() geeft 'SS' — één teken wordt twee, en elke code die ervan uitgaat dat case-conversie de string-lengte behoudt, is fout. Het Griekse Σ.toLowerCase() is context-gevoelig: σ midden in een woord, ς aan het einde van een woord.
Fix: gebruik toLocaleLowerCase() en toLocaleUpperCase() met een expliciete locale, of — als je de locale van de gebruiker niet kent — geef 'en-US' mee om het ASCII-compatibele gedrag te krijgen. De Case converter gebruikt de Intl-bewuste methoden zodat alle drie deze invoeren correct worden afgehandeld. Voor de regex-kant hiervan behandelt de Regex-spiekbrief de Unicode-letterklasse \p{L}.
4. Vervuiling door slimme aanhalingstekens
Plak een string uit Microsoft Word, Google Docs of macOS Notes in een case-converter en je sleept onzichtbare verstekelingen mee: U+2018 / U+2019 / U+201C / U+201D (gekrulde aanhalingstekens), U+2014 (em-dash), U+00A0 (niet-afbrekende spatie), U+200B (zero-width space). Alle vier zien er in de meeste fonts identiek uit aan hun ASCII-equivalenten, maar coderen anders. Een camelCase-identifier die een U+00A0 bevat, compileert in sommige talen en in andere niet, en je grep voor de variabelenaam mist het voorkomen zonder enig signaal.
Verdediging: normaliseer de invoer voor je tokeniseert. Een one-liner input.normalize('NFKC').replace(/[“”‘’]/g, '"') strijkt de meeste overtreders glad. Of gebruik de aanpak uit de Gids tekstvergelijking — vergelijk de verdachte string met zijn visuele ASCII-tweeling en spot de onzichtbaren in een hex-view.
5. URL’s moeten geen snake_case krijgen
https://example.com/api/users geplakt in een snake_case-converter levert https_example_com_api_users. Technisch een geldige snake_case-identifier; semantisch een ramp. URL’s zijn al in hun canonieke case (path/case met lowercase kebab-case-padsegmenten), en de hele URL als één identifier behandelen verliest de structurele informatie.
De fix is de URL parsen, de padsegmenten eruit halen en elk segment onafhankelijk converteren als dat echt nodig is. De Case converter parsed bewust geen URL’s automatisch, omdat de intentie van de gebruiker raden gevaarlijker is dan letterlijk zijn — plak een URL, krijg een letterlijke conversie; wilde je segment-voor-segment-gedrag, doe dat dan zelf.
6. dot.case versus property-toegang
De string user.profile.image is twee verschillende dingen, afhankelijk van de context. Als dot.case-identifier in een TOML-bestand is het één naam met drie segmenten. Als JavaScript-expressie is het de image-property van de profile-property van user.
Als je een dot.case-string uit een configuratiebestand kopieert en in een JavaScript-console plakt, probeert de runtime hem te evalueren als een property-ketting en krijg je een fout of iets verrassends terug. Omgekeerd komt code die JS-property-paden string-manipuleert ('a.b.c'.split('.')) soms uit met dot.case-identifiers van elders en behandelt die als diepere paden dan bedoeld. De twee moeten gescheiden blijven.
Conventie: dot.case-strings blijven binnen data (configuratiebestanden, MongoDB-paden, log-sleutels); code met één identifier gebruikt camelCase of snake_case; als je iets hiërarchisch in code nodig hebt, gebruik geneste objecten en de dot-property-syntaxis van de host-taal.
Recepten voor migratie tussen talen
JS camelCase naar Python snake_case
De snelste workflow: kopieer de JS-identifier, plak in een converter, kopieer de snake_case-uitvoer. Voor een code-niveau-conversie in bulk:
import { snakeCase } from 'change-case';
snakeCase('parseHTML'); // 'parse_html'
snakeCase('XMLHttpRequest'); // 'xml_http_request'
snakeCase('parseUTF8'); // 'parse_utf_8'
snakeCase('iPhone'); // 'i_phone'Die laatste is de valkuil — iPhone is een merknaam waar de camelCase-grens misleidend is. Voor merknamen en een handjevol historische identifiers: bewerk handmatig na de conversie.
SQL snake_case naar JS-/Java-API-responses
De meeste ORM’s doen dit automatisch voor je. Sequelize heeft underscored: true, TypeORM heeft de klasse SnakeNamingStrategy, Hibernate heeft de ImplicitNamingStrategyComponentPathImpl. De standaardmapping is user_profile_id ↔ userProfileId.
Wat stuk gaat: kolommen met acroniemen. Een kolom genaamd http_status_code round-tript netjes naar httpStatusCode, maar als je codebase HTTPStatusCode verkiest, zal de ORM met je vechten. Hernoem de kolom naar httpstatuscode_code (lelijk), configureer de ORM om acroniemen te behouden (zelden) of accepteer de standaardconventie.
React PascalCase-componenten naar CSS kebab-case-klassen
// UserProfileCard.tsx
export function UserProfileCard({ user }) {
return <div className="user-profile-card">{user.name}</div>;
}/* UserProfileCard.module.css */
.user-profile-card { padding: 1rem; }
.user-profile-card__avatar { border-radius: 50%; }
.user-profile-card--featured { background: gold; }BEM (Block Element Modifier) is de meest voorkomende CSS-klassenconventie die met React past: block is de componentnaam in kebab-case, element is block__element, modifier is block--modifier. Bestandsniveau: UserProfileCard.tsx voor de component, UserProfileCard.module.css voor de scoped stijlen — beide PascalCase, in overeenstemming met de componentnaam.
Omgevingsvariabelen naar applicatieconfiguratie
# .env (CONSTANT_CASE)
DATABASE_URL=postgres://localhost/myapp
MAX_RETRIES=3
LOG_LEVEL=info// Node.js
const dbUrl = process.env.DATABASE_URL;
const maxRetries = parseInt(process.env.MAX_RETRIES, 10);# Python
import os
db_url = os.environ['DATABASE_URL']
max_retries = int(os.environ['MAX_RETRIES'])De naam van de env-variabele blijft CONSTANT_CASE; de identifier aan applicatiekant volgt de variabelenconventie van de taal. YAML-/TOML-configuratiesleutels zijn per conventie snake_case (database_url, max_retries), ook al verwijzen ze tijdens runtime naar dezelfde CONSTANT_CASE-env-variabelen — frameworks als Spring, dotenv en Pydantic regelen de case-mapping voor je.
Vergelijking van libraries en tools
| Tool | Talen | Ondersteunde cases | Tokenizer-gedrag |
|---|---|---|---|
lodash (_.camelCase, etc.) | JavaScript | 4 hoofd + startCase | Acroniem-als-woord |
change-case npm-package | JavaScript/TS | Alle 8 programmeer-cases | Acroniem-als-woord |
inflection (Python) | Python | camelCase / snake_case | Acroniem-als-woord |
convert_case-crate | Rust | 12+ cases | Configureerbare acroniemen |
Go strings + regex | Go | Zelf bouwen | Project-gedefinieerd |
| VS Code (ingebouwd) | Editor | Alleen UPPER / lower / Title | Alleen witruimte |
| VS Code “change-case”-extensie | Editor | Alle 8 programmeer-cases | Acroniem-als-woord |
| Case converter | Browser | 15 cases (7 tekst + 8 code) | Acroniem-als-woord |
Voor dagelijkse code: installeer change-case (JS) of convert_case (Rust). Voor Python is de inflection-package de canonieke keuze, maar een kleine handgeschreven regex dekt 90% van de gevallen. Voor eenmalige conversies tijdens een code review of refactor toont de Case converter alle 15 uitvoeren in één plak-actie, zodat je ze in één oogopslag kunt vergelijken. Moet je tokens tellen of de lengte van een identifier valideren, dan dekt de Woordenteller die kant; voor het verifiëren van een tokenizer-regex gebruik je de Regex-tester met de patronen uit de hierboven gelinkte spiekbrief.
FAQ
Wat is het verschil tussen camelCase en PascalCase?
camelCase begint met een kleine letter (userProfile); PascalCase begint met een hoofdletter (UserProfile). Beide schrijven elk volgend woord met een hoofdletter zonder scheidingsteken. camelCase is de conventie voor variabelen en functies in de meeste C-familie-talen; PascalCase is de conventie voor klassen, types en React-componenten.
Waarom gebruikt Python snake_case maar JavaScript camelCase?
Python (1991) erfde snake_case van C en de ABC-taal, daarna codificeerde PEP 8 het als de community-standaard. JavaScript (1995) kopieerde de camelCase-stijl van Java, en Java had camelCase weer geërfd van Smalltalk. Beide zijn historische padafhankelijkheden. Geen van beide conventies is technisch beter — leesbaarheidsonderzoek staat ruwweg gelijk — en consistentie binnen een ecosysteem doet er meer toe dan de keuze zelf.
Moet ik parseUrl of parseURL gebruiken voor acroniemen in camelCase?
parseUrl (acroniem-als-woord) is de moderne standaard — gebruikt door Google, Apple, lodash en de change-case-npm-package. parseURL (acroniem-hoofdletters bewaren) is de Microsoft .NET-stijl en domineert in C#-code. Kies voor een nieuw project in JavaScript, TypeScript of Swift parseUrl omdat die schoon round-tript door snake_case- en kebab-case-conversies. Wat je ook kiest, leg het vast in je linter.
Is kebab-case beter dan snake_case voor URL’s?
Ja. Google’s officiële Search Central-richtlijn is om koppeltekens te gebruiken, geen underscores, in URL’s. Zoekindexeerders tokeniseren op koppeltekens maar niet op underscores: /user-profile wordt geïndexeerd als user + profile, terwijl /user_profile wordt geïndexeerd als de enkele term user_profile. De impact op de ranking is per pagina klein maar reëel, en lowercase kebab-case-URL’s vermijden ook bugs rond hoofdlettergevoeligheid op Linux-servers.
Welke case moeten database-kolomnamen gebruiken?
snake_case. Elke grote ORM (SQLAlchemy, Hibernate, Sequelize, TypeORM, Active Record) gebruikt het standaard, en elk groot SQL-dialect handelt het identiek af. PostgreSQL vouwt niet-aangehaalde identifiers naar lowercase, MySQL is hoofdlettergevoelig op Linux en hoofdletterongevoelig op macOS/Windows, en SQLite behandelt namen als ondoorzichtig. Lowercase snake_case is de enige spelling die zich overal hetzelfde gedraagt.
Kan ik naamgevingsconventies binnen één project mengen?
Ja — en meestal moet dat ook. Een typische webapp gebruikt mogelijk camelCase voor JS-variabelen, snake_case voor de database, kebab-case voor CSS-klassen en URL’s, en CONSTANT_CASE voor env-variabelen. De regel is “één conventie per laag, nooit binnen een enkele laag mengen”. Leg de keuze per laag vast in je linter of style-gids, zodat PR-reviews er geen woord meer aan vuilmaken.
Hoe converteer ik programmatisch tussen cases?
Installeer voor JavaScript en TypeScript change-case of gebruik lodash’s _.camelCase / _.snakeCase / _.kebabCase. Voor Python: de inflection-package of een korte regex (re.sub(r'(?<!^)(?=[A-Z])', '_', s).lower() voor PascalCase naar snake_case). Voor Rust: de convert_case-crate. Voor eenmalige interactieve conversies toont de Case converter alle 15 case-uitvoeren voor elke invoer op één browserpagina.
Is CONSTANT_CASE alleen voor omgevingsvariabelen?
Nee, maar env-variabelen zijn het meest voorkomende gebruik. CONSTANT_CASE is voor elke “runtime-invariant”: MAX_RETRIES, API_BASE_URL, DEFAULT_PAGE_SIZE, enum-waarden, macrodefinities, top-level configuratieconstanten. De regel is “zou deze tijdens runtime veranderen een bug zijn?” — zo ja, CONSTANT_CASE; zo nee, de normale variabelenconventie van de taal. const result = await fetch(url) is prima zoals het is.
Wat is het verschil tussen dot.case en path/case?
dot.case gebruikt . als scheidingsteken (user.profile.image) en representeert een hiërarchische sleutel binnen data: Java-packages, MongoDB-veldpaden, TOML-configuratiesleutels, Lodash get/set-paden. path/case gebruikt / (user/profile/image) en representeert een echte locatie: URL-paden, bestandssysteempaden, Git-refs. De keuze tussen punten en schuine strepen signaleert “data-label” tegenover “feitelijke locatie”.
De beslissingskaart van 30 seconden
Drie regels die 95% van de vragen afdekken:
-
Kopieer voor code-identifiers de standaardbibliotheek van je taal. Python: snake_case voor variabelen en functies, PascalCase voor klassen. JavaScript en TypeScript: camelCase voor variabelen en functies, PascalCase voor klassen en componenten. Go: kleine letter als eerste voor package-private, hoofdletter als eerste voor geëxporteerd. Rust: snake_case voor variabelen en functies, PascalCase voor types, SCREAMING_SNAKE voor constanten.
-
Voor de cross-cutting lagen ligt de case vast, ongeacht de taal. URL’s zijn kebab-case. CSS-klassen zijn kebab-case. Database-kolomnamen zijn snake_case. Omgevingsvariabelen zijn CONSTANT_CASE. HTTP/1.1-headers zijn Header-Case (HTTP/2 normaliseert naar lowercase op de draad).
-
Leg de keuze één keer vast in je linter en stop met discussiëren. ESLint, Pylint, Clippy, golangci-lint en Rubocop hebben er allemaal regels voor. Kies de conventie, configureer de linter, en de volgende PR-review besteedt geen woord meer aan
userIDversususerId.
Wanneer je echt tussen cases moet converteren — voor een refactor, een CMS-migratie, een SQL-naar-API-mapping — geeft de Case converter je alle 15 case-uitvoeren in één plak-actie, zodat je de juiste kunt kopiëren zonder handmatig de invoer te tokeniseren. Voor verwant tekstwerk: zie de Woordenteller, Regex-tester en Tekst vergelijken online. Voor diepere stof behandelt de Regex-spiekbrief de tokenizer-patronen, dekt de Gids tekstvergelijking voor- en na-vergelijkingen tijdens een migratie, en behandelt de Gids teken- en woordlimieten URL-lengtebudgetten voor SEO-slugs.