Convertisseur de casse pour identifiants

Qu’est-ce que la casse d’un identifiant ?

La casse d’un identifiant est la convention par laquelle un programmeur réunit plusieurs mots en un seul nom. JavaScript et Java privilégient camelCase, Python et Rust emploient snake_case, les classes CSS et les URL utilisent kebab-case, les noms de types sont généralement en PascalCase et les constantes, par convention, en SCREAMING_SNAKE_CASE. Toutes encodent les mêmes mots ; seule la jonction change.

Cette page détecte dans quelle convention un nom se trouve déjà, le convertit vers toutes les autres, et vous dit ce que presque aucun convertisseur ne dit : si la conversion perd une information que vous ne pourrez pas récupérer.

C’est le pendant, côté développeur, du convertisseur de casse de ce site, qui traite la prose — majuscule en début de phrase, casse de titre et règles de capitalisation de la langue. Rien ici ne relève de la grammaire.

Comment l’utiliser

1. Collez ou tapez n’importe quel identifiant. Il reconnaît camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE, Train-Case et dot.case. Une chaîne qui n’entre dans aucune est déclarée non reconnue plutôt que forcée vers la plus proche.
2. Regardez le découpage en mots. Toute conversion tient aux deux mêmes étapes — découper le nom en mots, puis les rejoindre autrement — si bien que la liste de mots vous dit exactement ce que l’outil croit lire. Si le découpage est faux, toutes les conversions en dessous le seront aussi.
3. Copiez la forme dont vous avez besoin. Chaque ligne a son bouton de copie, et celle qui correspond à votre saisie est signalée. En dessous, une note indique si convertir puis reconvertir rendrait le nom de départ.

Deux bibliothèques, deux réponses, et la cause tient aux chiffres

Avant d’écrire ceci, nous avons pris deux bibliothèques de conversion de casse très répandues — l’une dédiée aux casses, l’autre les fonctions de casse d’une bibliothèque utilitaire généraliste — et les avons passées sur tous les identifiants camelCase et PascalCase déclarés dans le code de ce site : 5 159 noms. Elles ont divergé sur 71, soit environ 1,38 %.

Chacune des divergences, sans exception, tenait à un chiffre. Une bibliothèque garde le chiffre collé aux lettres qui précèdent, si bien que Base64Tool devient base64_tool ; l’autre traite le chiffre comme un mot à part et produit base_64_tool. Idem pour utf8Bytes, rot13, mulberry32 et byAlpha2. Nous avons classé les 71 et le résidu est nul : aucune seconde cause ne se cachait derrière la première.

Aucune des deux n’a tort. Il n’existe pas de norme là-dessus, et les deux lectures correspondent à deux idées raisonnables de ce qu’est un chiffre : partie d’un mot, comme le 64 de Base64, ou jeton distinct, comme un numéro de version. Cet outil garde les chiffres collés, donc Base64 fait un seul mot, et il vaut la peine de savoir que l’outil d’un collègue peut faire autrement.

La conséquence pratique est mince mais tranchante : si vous générez un nom de colonne à partir d’un nom de classe avec un outil et que vous interrogez cette colonne depuis du code qui en emploie un autre, base64_tool et base_64_tool ne correspondront pas et rien ne vous dira pourquoi.

Ce que la conversion détruit, et à quelle fréquence

L’échec célèbre, ce sont les sigles. XMLHttpRequest devient xml_http_request, et le retour donne XmlHttpRequest : les trois majuscules ont disparu et rien dans la forme snake_case ne garde trace de leur existence. Même chose pour parseURL, IOError et APIKey. Ce n’est le défaut d’aucune bibliothèque en particulier : l’information est réellement absente de la forme intermédiaire.

Ce qui mérite d’être ajouté, parce que presque personne ne le fait, c’est la fréquence réelle du problème. Sur ces mêmes 5 159 identifiants, quatre seulement comportaient deux majuscules consécutives ou plus — moins d’un dixième de point de pourcentage — et les quatre ont malgré tout survécu à l’aller-retour. Dans ce code, le cas avec perte ne s’est pas produit une seule fois.

C’est un seul corpus, et un corpus TypeScript, où des noms comme getElementById sont la norme. Un code Java ou C# truffé de HTTPSConnection et de XMLParser donnerait tout autre chose, et nous ne prétendons pas le contraire. Mais l’idée reçue prend le problème à l’envers : on décrit la conversion comme peu fiable alors que la version honnête est qu’elle perd de l’information dans un cas précis et repérable, rare dans le nommage moderne.

Il y a une seconde moitié à connaître. Une fois un nom en snake_case, il est stable : le reconvertir ne change rien, et le camelCase qui en découle reste le même quel que soit le nombre de tours. La perte a lieu une fois, à l’aller, et jamais ensuite. La règle est donc simple : convertissez depuis votre original autant que vous voulez, mais ne traitez pas un nom déjà converti comme une source à partir de laquelle restaurer.

Limites honnêtes

Le découpage en mots constitue tout le moteur, et il prend deux décisions que cette page énonce plutôt que de les taire. Les chiffres restent collés aux lettres précédentes. Et une suite de majuscules suivie d’un mot capitalisé se coupe avant la dernière majuscule, si bien que HTTPServer donne http et server au lieu d’éclater en lettres isolées — ce que l’outil ferait sans cette règle, et qui constitue l’un des sabotages de la suite de tests.

La détection est volontairement stricte. Une chose comme mixed_Snake-kebab ne satisfait aucune convention : elle est donc signalée comme non reconnue plutôt qu’attribuée à la plus proche. Un détecteur qui devine toujours paraît plus capable et vous apprend moins.

Une ambiguïté réelle n’a pas de bonne réponse. Un seul mot en minuscules — total, nom, valeur — est à la fois du camelCase valide et du snake_case valide à un mot. L’outil le nomme camelCase, parce que c’est la lecture la plus courante pour un identifiant, mais c’est une convention et non un fait.

Enfin, ceci traite des identifiants ASCII. La plupart des langages admettent des lettres au-delà de A–Z dans les noms, et les règles de suites de majuscules employées ici sont écrites pour l’alphabet latin. Un nom en grec ou en cyrillique sera coupé sur les séparateurs, mais pas sur les changements de casse.

Pourquoi est-ce gratuit ?

Parce que c’est une expression régulière et une jonction de chaînes. Tout s’exécute dans votre navigateur, rien de ce que vous tapez n’est envoyé, et aucun serveur n’intervient pour renommer une variable.

Il n’y a donc ni compte, ni inscription, ni rien de réservé. Le moteur et sa suite de tests se trouvent dans le dépôt, à côté de la page, et les tests confrontent leurs affirmations aux plus de 5 000 identifiants du site lui-même plutôt qu’à des exemples inventés — la population même dont proviennent les chiffres ci-dessus, de sorte que l’article et les tests ne peuvent pas diverger.