Sofort in 14 Formate konvertieren
Jede Programmiersprache hat eigene Konventionen: JavaScript nutzt camelCase für Variablen und PascalCase für Klassen, Python und Ruby setzen auf snake_case, CSS und URLs verlangen kebab-case, Konstanten sind oft SCREAMING_SNAKE_CASE. Mit diesem Tool wechselst du in einem Klick zwischen allen gängigen Konventionen — ohne manuelle Tipp-Arbeit.
Bevor Text in eine andere Schreibweise konvertiert wird, muss er in einzelne Worter zerlegt werden. Das klingt trivial, ist aber die schwierigste Aufgabe des Tools. Eingaben wie parseHTMLString, getURL2API oder kebab-case_mixed.example enthalten gleichzeitig Camel-Grenzen, Akronyme, Trennzeichen und Zahlen. Ein robuster Algorithmus arbeitet in drei Schritten: erst ein Split an Stellen wie aA (Wechsel von Klein- zu Grossbuchstabe), dann ein Split an Akronym-Grenzen wie HTMLParser zu HTML plus Parser, schliesslich ein Split an allen Sonderzeichen wie _, -, . und /. Die Unicode-Spezifikation UAX #29 (Text Segmentation) beschreibt diesen Prozess formal als Word-Boundary-Detection.
Akronyme sind der haufigste Stolperstein. Wandelt man XMLHttpRequest naiv in snake_case um, entsteht x_m_l_http_request — funktional korrekt, aber unlesbar. Die meisten Bibliotheken (lodash, change-case, Google Java Style Guide) raten dazu, mehrbuchstabige Akronyme als einzelnes Wort zu behandeln. Das ergibt xml_http_request und XmlHttpRequest statt XMLHTTPRequest. Google selbst hat 2017 seinen Style Guide angepasst und schreibt seitdem parseHtml() statt parseHTML(). Wer alten Code refaktorisiert, sollte diese Regel kennen — sonst entstehen subtile Diff-Konflikte bei Code-Reviews.
Auch Zahlen erzeugen Mehrdeutigkeiten. Soll iPad2Pro zu i_pad_2_pro, i_pad2_pro oder i_pad2pro werden? Die Convention bei Rust (RFC 430) lautet: Ziffern bleiben am vorherigen Token kleben (i_pad2_pro), wahrend Microsoft .NET sie als eigenstandige Komponenten behandelt. Wir folgen der Rust-Konvention, weil sie kompakter ist und in der Praxis weniger Konflikte mit Domain-spezifischen Bezeichnungen wie HTML5, ES2024 oder UTF8 verursacht. Wer in einem Team arbeitet, sollte diese Detail-Regel im Style-Guide festhalten — sie verhindert spatere Renames, die als einzige Anderung in Pull-Requests auftauchen. Eine weitere oft ubersehene Falle sind Reserved Words: konvertiere class in PascalCase zu Class, und du hast in C#, Java oder Python eine ungultige Bezeichnung. Style-Guides empfehlen entweder ein Suffix (UserClass) oder ein Prafix (cls_user) — der Konverter kann das nicht automatisch erkennen, weil die Reserved-Word-Liste sprachabhangig ist.
Bei groberen Refactorings hilft ein systematischer Ablauf, damit nichts ubersehen wird:
old_user_id, oldUserId, OLD_USER_ID.camelCase fur JS/Java, snake_case fur Python/SQL, kebab-case fur CSS/URLs.HTTP, ID, URL erscheinen jetzt als ganzes Wort (http/Http).obj["old_user_id"]) wird der String nicht automatisch mitgerenamed.Diese typischen Konvertierungen zeigen, wie das Tool mit gemischter Eingabe umgeht:
getUserById → snake_case → get_user_by_id (Python-Funktion).background-color → camelCase → backgroundColor (CSS-Property in JS-DOM).MAX_RETRY_ATTEMPTS → PascalCase → MaxRetryAttempts (C#-Konstante umbenannt zu Enum-Member).parseXMLDocument → kebab-case → parse-xml-document (Akronym bleibt als Token).order.items[0].productId → snake_case (alle Segmente) → order.items[0].product_id.Der Konverter ist ein Text-Tool, kein Refactoring-Tool. Er versteht keinen Scope: let userId innerhalb einer Funktion kann ohne weiteres in user_id umbenannt werden, aber wenn die Variable als JSON-Property nach aussen geht, andert sich die API. Ebenso wenig erkennt das Tool Domain-Akronyme aus Branchen-Vokabular: iOSAppId mag in einem Kontext iOS-App-Id, in anderem i-os-app-id bedeuten — der Algorithmus muss eine Wahl treffen. Fur Massen-Refactorings in Produktionscode immer mit jscodeshift, ast-grep oder dem IDE-eigenen Rename-Refactoring arbeiten, das den Symbolgraphen kennt. Der Converter ist optimal fur Einzelfalle, Datenbankschemata, CSS-zu-JS-Property-Maps und Style-Guide-Migrationen. Ein weiterer Punkt: bei Sprachen mit Akzent-Zeichen wie Franzosisch oder Spanisch kann der Konverter nicht entscheiden, ob aus Cafe ein CAFE oder ein CAFE (Akzent erhalten) werden soll — wir erhalten den Akzent. Unicode-Normalisierung (NFC vs. NFD) ist ein eigenes Thema, das oft in Datei- und Datenbank-Imports zu unentdeckten Duplikaten fuhrt.
XMLParser wird in zwei Token gesplittet (XML + Parser), nicht in vier — analog zur lodash- und Google-Konvention.snake_case (PostgreSQL-Konvention, Rails-Default). Quoted Identifiers in PostgreSQL bewahren Camel-Case ("userId"), erzwingen aber Quoting in jeder Query — generell unbequem.?data=... Parameter in die URL geschrieben (bis 1000 Zeichen). Beim Offnen des Links sieht der Empfanger sofort dasselbe Ergebnis.