Schrijfwijzeconverter
Wissel tussen camelCase, snake_case, kebab-case, PascalCase en meer
Over deze tool
Identifiers reizen voortdurend tussen conventies: de API geeft snake_case terug, je TypeScript wil camelCase, de CSS-klasse heeft kebab-case nodig en de omgevingsvariabele eist CONSTANT_CASE. Deze converter neemt willekeurige gemengde invoer — spaties, underscores, koppeltekens, bestaande camelCase — splitst die verstandig in woorden en voegt ze meteen in negen doelstijlen weer samen.
De splitser begrijpt de lastige gevallen: hij breekt “getUserByID” op in get/user/by/id (waarbij het acroniem tot de grens intact blijft), rekent cijfers bij hun woord en verwerkt elke regel apart, zodat je een hele kolom databasevelden kunt plakken en in één keer kunt omzetten.
Elke stijl wordt tegelijk getoond met een kopieerknop per rij — je hoeft geen modus vooraf te kiezen, gewoon plakken en pakken wat je nodig hebt.
Veelgestelde vragen
- Hoe worden acroniemen als “HTTPResponse” behandeld?
- Een reeks hoofdletters gevolgd door een kleine letter wordt gesplitst vóór de laatste hoofdletter: HTTPResponse → http + response. Dat komt overeen met hoe de meeste stijlgidsen acroniemen willen tokeniseren, al kan geen enkele splitser de bedoeling perfect raden — randgevallen als “IOError” worden io + error.
- Kan ik veel identifiers tegelijk omzetten?
- Ja — elke regel wordt apart omgezet. Plak een lijst kolomnamen, één per regel, en de uitvoer behoudt de regelstructuur in de nieuwe stijl.
- Wat is hier het verschil tussen Title Case en Sentence case?
- Title Case zet elk woord met een hoofdletter (“User Account Id”); Sentence case alleen het eerste (“User account id”). Geen van beide past de redactionele regels over lidwoorden en voorzetsels toe — voor identifiers wil je die vrijwel nooit.
- Waarom levert heen en weer converteren niet altijd mijn origineel op?
- Het splitsen in woorden gooit informatie weg — “user_ID_2” en “userId2” tokeniseren identiek. Conversies zijn vooruit deterministisch, maar de oorspronkelijke schrijfwijze van de woordgrenzen valt niet altijd terug te construeren.