Le cas curieux des ternaires

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Le formatage des ternaires a toujours été problématique, et nous y apportons enfin une solution en v3.1.0 avec un style de formatage innovant.

Découvrez notre parcours et la motivation derrière ce changement, accompagnés des retours initiaux des développeurs et d'un aperçu du style des "ternaires curieux".

Testez l'option --experimental-ternaries et dites-nous ce que vous en pensez !

Pour un résumé rapide, consultez l'annonce de version.

Introduction

Formater élégamment des ternaires imbriqués dans divers scénarios s'avère étonnamment complexe.

Les développeurs les trouvent depuis longtemps si déroutants à lire qu'ils finissent par refactoriser leur code en une série disgracieuse de if-else, souvent avec une déclaration let, une IIFE ou une fonction séparée.

Selon les bêta-testeurs, le nouveau style que nous avons développé demande un temps d'adaptation, mais permet finalement d'utiliser les ternaires comme forme concise d'expressions if-else dans les bases de code modernes.

Contexte historique

L'approche naïve initiale de Prettier – simplement indenter chaque niveau d'un ternaire imbriqué – fonctionnait bien dans des cas simples, mais ne s'adapte évidemment pas aux longues chaînes de ternaires et posait d'autres problèmes.

En 2018, nous l'avons donc remplacée par des ternaires à plat, ce qui semblait une bonne idée à l'époque, mais a été mal accueilli – l'issue demandant son annulation a dépassé les 500 votes positifs.

Bien que nous soyons finalement revenus aux ternaires indentés, nous voulions trouver une meilleure solution.

Ces dernières années, nous avons exploré et testé de très nombreuses alternatives visant à conserver la lisibilité des ternaires indentés dans les cas courants, tout en s'adaptant à une plus grande variété de situations.

Critères exigeants

Idéalement, nous souhaitions une approche unique répondant à nos exigences :

1. Dans tous les cas, il doit être facile d'identifier "le if", "le then" et "le else" – et leur correspondance.

2. Le code doit passer fluidement d'un ternaire isolé à une chaîne de 2 éléments, puis à une longue série de cas simples, jusqu'à des structures complexes avec quelques conditions imbriquées. (La plupart des alternatives échouaient ici).

3. La syntaxe en JSX, dans les expressions conditionnelles TypeScript (inexprimables avec if) et en JavaScript standard doit être visuellement cohérente.

4. L'approche doit supporter des chaînes ternaires imbriquées de longueur arbitraire (comme un type conditionnel TypeScript avec des dizaines de cas).

Les ternaires indentés échouaient clairement sur (4), probablement sur (1), et même sur (3) – nous avons presque toujours formaté les ternaires JSX de manière plate mais lisible, ce qui semblait artificiel hors du contexte JSX.

De nombreuses personnes dans la communauté étaient enthousiastes à l'idée d'un style "case", s'inspirant de la syntaxe match de langages comme Rust ou OCaml, mais cette approche ne répondait pas au critère (2) et d'autres objectifs.

Une solution surprenante

La bonne nouvelle : nous avons trouvé un algorithme de formatage répondant à nos critères. La mauvaise : il est novateur et donc inhabituel pour la plupart des développeurs.

Lors des tests bêta, nous avons constaté un scepticisme initial :

Mais après une courte période d'utilisation, les retours étaient positifs :

Un autre développeur témoigne :

La première heure avec cette règle activée, c'était un peu étrange. Mais dès la deuxième heure, je l'ai utilisée plusieurs fois pour résoudre des problèmes qui auraient autrement nécessité des refontes laides en if. Je ne reviendrai pas en arrière.

Je détestais les ternaires imbriqués, mais je déteste aussi transformer une ligne de code élégante en if-else. La nouvelle règle ajoute une expression if-else, if-else linéaire et compréhensible au langage, bien plus agréable que des ternaires multiples en branches imbriquées.

Nous avions donc une formule gagnante, mais anticipions une adoption déroutante pour la communauté.

Nous avons donc décidé de proposer ce formatage via une option temporaire --experimental-ternaries pendant quelques mois, tout en livrant ce que la communauté réclamait : les ternaires indentés.

Aperçu du style

À quoi ressemble ce nouveau style exactement ?

Voici un exemple rapide pour illustrer la logique des "curious ternaries" :

const animalName =
  pet.canBark() ?
    pet.isScary() ?
      'wolf'
    : 'dog'
  : pet.canMeow() ? 'cat'
  : 'probably a bunny';

1. Toute ligne terminée par un point d'interrogation est un "if".

   • foo ? équivaut à poser une question sur foo – "si foo ? alors, …".

2. Toute ligne commençant par : est un "else".

   • : foo signifie "sinon, foo".
   • : foo ? signifie "sinon, si foo ?".

3. Toute ligne sans : ni ? est un "then".

   • foo signifie simplement "alors foo".

Voici le code reformaté en style "case" :

const animalName =
  pet.isScary() ? 'wolf'
  : pet.canBark() ? 'dog'
  : pet.canMeow() ? 'cat'
  : 'probably a bunny';

On obtient ainsi une syntaxe concise approchant le match en JavaScript, avec le simple opérateur ternaire (bien qu'il manque plusieurs fonctionnalités).

Notre nouveau formatage fusionne fluidement les ternaires "curious" (point d'interrogation en fin de ligne) et "case-style" (point d'interrogation au milieu).

Par exemple :

const animalName =
  pet.canSqueak() ? 'mouse'
  : pet.canBark() ?
    pet.isScary() ?
      'wolf'
    : 'dog'
  : pet.canMeow() ? 'cat'
  : pet.canSqueak() ? 'mouse'
  : 'probably a bunny';

Donnez-nous votre avis !

Nous espérons que vous apprécierez le nouveau format par défaut plus lisible, et nous vous encourageons vivement à tester l'option --experimental-ternaries pendant quelques semaines pour nous faire part de vos impressions.

Veuillez nous transmettre vos retours via Google Forms : https://forms.gle/vwEuboCobTVhEkt66