Kernighan sur la clarté du code : le goût plutôt que le code malin

Pourquoi Kernighan compte encore pour le code de tous les jours

Le nom de Brian Kernighan apparaît partout où de nombreux développeurs l’utilisent sans y penser : outils Unix classiques, écosystème C, et des décennies d’écrits qui ont appris aux gens à expliquer les programmes clairement. Que vous vous rappeliez The C Programming Language (avec Dennis Ritchie), The Unix Programming Environment, ou ses essais et conférences, le fil commun est une insistance sur des idées simples exprimées proprement.

La clarté dépasse les langages et frameworks

Le meilleur conseil de Kernighan ne dépend pas de la syntaxe C ni des conventions Unix. Il porte sur la manière dont les humains lisent : nous recherchons la structure, nous nous fions aux noms, nous inférons l’intention, et nous sommes perdus quand le code cache le sens derrière des astuces. C’est pourquoi le « goût » pour la lisibilité compte toujours quand vous écrivez en TypeScript, Python, Go, Java ou Rust.

Les langages changent. Les outils s’améliorent. Les équipes livrent toujours des fonctionnalités sous pression, et la plupart du code est maintenu par quelqu’un d’autre que l’auteur original (souvent vous du futur). La clarté est le multiplicateur qui rend tout cela viable.

Ce sur quoi cet article se concentre

Ce n’est pas un éloge du « hero coding » ni un appel à mémoriser des règles rétro. C’est un guide pratique des habitudes qui rendent le code de tous les jours plus facile à manipuler :

• choisir des solutions directes plutôt que des raccourcis malins
• façonner fonctions et modules pour que leur but soit évident
• documenter les décisions sans noyer le lecteur sous les commentaires
• utiliser les revues et la refactorisation pour garder le code compréhensible au fil de sa croissance

L’influence de Kernighan importe parce qu’elle pointe vers un objectif simple et convivial pour l’équipe : écrire du code qui communique. Quand le code se lit comme une explication claire, vous passez moins de temps à le décoder et plus de temps à l’améliorer.

Ce que signifie le « bon goût » en lisibilité

Le « bon goût » pour un code lisible n’est pas une affaire de style personnel, de patterns sophistiqués ou de compresser une solution en moins de lignes. C’est l’habitude de choisir l’option la plus simple et la plus claire qui communique de manière fiable l’intention.

Une solution de bon goût répond à une question basique pour le lecteur suivant : Que cherche à faire ce code, et pourquoi le fait-il de cette façon ? Si cette réponse exige des acrobaties mentales, des hypothèses cachées, ou de décoder des astuces, le code coûte du temps à l’équipe.

La lisibilité est pour les autres (et pour le vous du futur)

La plupart du code est lu bien plus souvent qu’il n’est écrit. Le « bon goût » traite la lecture comme l’activité principale :

• Il suppose qu’un coéquipier va survoler ce fichier sous pression.
• Il suppose que vous reviendrez des mois plus tard avec moins de contexte.
• Il suppose que le lecteur peut ne pas partager vos préférences, raccourcis ou souvenirs de la discussion initiale.

C’est pourquoi la lisibilité n’est pas seulement esthétique (indentation, largeur de ligne, ou snake_case). Ces éléments aident, mais le « bon goût » concerne surtout la facilité de raisonnement : noms clairs, flux de contrôle évident, et structure prévisible.

Le compromis : un peu plus long peut être mieux

Une erreur courante est d’optimiser pour la brièveté au lieu de la clarté. Parfois, le code le plus clair est un peu plus long parce qu’il explicite les étapes.

Par exemple, comparez deux approches :

• Un one-liner compact qui filtre, transforme et gère les cas limites en une seule expression.
• Quelques variables intermédiaires nommées qui expliquent la séquence : valider → normaliser → calculer → retourner.

La deuxième version peut ajouter des lignes, mais réduit la charge cognitive nécessaire pour vérifier la correction. Elle rend aussi les bugs plus faciles à isoler et les changements plus sûrs à appliquer.

Le bon goût, c’est savoir quand arrêter d’« améliorer » une solution par la malice et, à la place, rendre l’intention manifeste. Si un collègue peut comprendre le code sans vous demander une visite guidée, vous avez bien choisi.

La taxe de la débrouillardise dans les équipes réelles

Le code malin donne souvent l’impression d’une victoire sur le moment : moins de lignes, une astuce élégante, un effet « wow » dans le diff. Dans une vraie équipe, cette débrouillardise devient une facture récurrente — payée en temps d’intégration, en temps de revue, et en hésitation chaque fois que quelqu’un doit toucher le code.

Où la taxe apparaît au quotidien

L’intégration ralentit. Les nouveaux coéquipiers doivent non seulement apprendre le produit ; ils doivent aussi apprendre votre dialecte privé de raccourcis. Si comprendre une fonction exige de décoder des opérateurs astucieux ou des conventions implicites, les gens éviteront de la modifier — ou le feront avec peur.

Les revues s’allongent et deviennent moins fiables. Les reviewers dépensent de l’énergie à prouver que l’astuce est correcte plutôt qu’à évaluer si le comportement correspond à l’intention. Pire, le code malin est plus difficile à simuler mentalement, si bien que les reviewers ratent des cas limites qu’ils auraient attrapés dans une version simple.

Les coûts cachés qu’on ne remarque que plus tard

La débrouillardise se cumule pendant :

• Le débogage : les expressions denses cachent les valeurs intermédiaires, rendant l’insertion de logs ou l’inspection d’état plus difficile.
• La gestion d’incident : sous pression, l’équipe a besoin d’un code qui se lit comme une liste d’instructions, pas comme un puzzle.
• Les transferts et rotations : quand la propriété change, « ça marche » ne suffit pas ; la personne suivante doit pouvoir raisonner rapidement à son sujet.

Motifs « malins » courants qui nuisent silencieusement

Quelques récidivistes :

• Nombres magiques et constantes inexpliquées (17, 0.618, -1) qui codent des règles que personne ne se rappelle.
• One-liners denses qui mélangent parsing, validation, transformation et effets de bord dans une seule instruction.
• Opérateurs et priorités piégeux (ternaires imbriqués, hacks bitwise, astuces de && / ||) qui reposent sur la connaissance de règles d’évaluation subtiles.

L’idée de Kernighan sur le « goût » réapparaît ici : la clarté n’est pas écrire plus ; c’est rendre l’intention évidente. Si une version « intelligente » économise 20 secondes aujourd’hui mais coûte 20 minutes à chaque lecteur futur, elle n’est pas intelligente — elle est chère.

Petites victoires de clarté : noms, mise en page et flux de contrôle

Le « goût » de Kernighan se manifeste souvent dans de petites décisions répétables. Vous n’avez pas besoin d’un grand refactor pour rendre le code plus vivable — les petites victoires de clarté se cumulent chaque fois que quelqu’un parcourt un fichier, cherche un comportement ou corrige un bug sous pression.

Noms : faites raconter l’histoire au code

Un bon nom réduit le besoin de commentaires et rend les erreurs plus difficiles à masquer.

Visez des noms révélant l’intention qui correspondent au vocabulaire de l’équipe :

• Préférez invoiceTotalCents à sum.
• Utilisez un terme de manière cohérente (choisissez customer ou client, pas les deux).
• Évitez les abréviations « malines » sauf si elles sont standard dans votre base de code.

Si un nom vous oblige à le décoder, il fait l’inverse de son travail.

Mise en page : formatez pour le scan, pas pour frimer

La plupart de la lecture est un balayage. Un espacement et une structure cohérents aident l’œil à trouver l’essentiel : limites de fonctions, conditionnels et le « happy path ».

Quelques habitudes pratiques :

• Gardez les lignes liées ensemble ; séparez les étapes par des lignes vides.
• Alignez le code pour faire ressortir la structure (l’indentation doit expliquer l’imbrication).
• Utilisez des retours précoces pour garder le flux principal visible.

Flux de contrôle : préférez des branchements simples aux imbrications astucieuses

Quand la logique devient tricky, la lisibilité s’améliore généralement en rendant les décisions explicites.

Comparez ces deux styles :

// Harder to scan
if (user \u0026\u0026 user.active \u0026\u0026 !user.isBanned \u0026\u0026 (role === 'admin' || role === 'owner')) {
  allow();
}

// Clearer
if (!user) return deny('missing user');
if (!user.active) return deny('inactive');
if (user.isBanned) return deny('banned');
if (role !== 'admin' \u0026\u0026 role !== 'owner') return deny('insufficient role');

allow();

La seconde version est plus longue, mais elle se lit comme une checklist — et il est plus simple de l’étendre sans casser quoi que ce soit.

Ce sont des choix « petits », mais c’est l’art quotidien du code maintenable : des noms honnêtes, un formatage qui guide le lecteur, et un flux de contrôle qui évite les acrobaties mentales.

Fonctions et modules faciles à comprendre

Le style de clarté de Kernighan apparaît surtout dans la façon de découper le travail en fonctions et modules. Un lecteur doit pouvoir parcourir la structure, deviner ce que fait chaque pièce, et être majoritairement dans le vrai avant de lire les détails.

Une fonction, un seul travail

Visez des fonctions qui font exactement une chose à un seul « niveau de zoom ». Quand une fonction mélange validation, règles métier, formatage et I/O, le lecteur doit garder plusieurs fils en tête.

Un test rapide : si vous vous surprenez à écrire des commentaires comme “// now do X” dans une fonction, X est souvent un bon candidat pour une fonction séparée avec un nom clair.

Gardez les paramètres simples (et courts)

Les longues listes de paramètres sont une taxe de complexité cachée : chaque site d’appel devient un mini-fichier de configuration.

Si plusieurs paramètres voyagent toujours ensemble, regroupez-les de manière réfléchie. Les objets d’options (ou petites structures de données) peuvent rendre les points d’appel explicites — si vous gardez le groupe cohérent et évitez de tout fourrer dans un sac « misc ».

Privilégiez aussi le passage de concepts du domaine plutôt que des primitifs. UserId vaut mieux que string, et DateRange vaut mieux que (start, end) quand ces valeurs ont des règles.

Petits modules, frontières claires

Les modules sont des promesses : « tout ce dont vous avez besoin pour ce concept est ici, et le reste est ailleurs. » Gardez les modules assez petits pour pouvoir tenir leur but en tête, et concevez des frontières qui minimisent les effets de bord.

Habitudes pratiques :

• Rendez les dépendances explicites (entrées en, sorties hors) plutôt que de fouiller l’état global.
• Conservez l’I/O aux frontières : la logique centrale doit être testable sans base de données, système de fichiers ou réseau.
• Exposez une petite surface publique ; gardez les helpers privés.

Quand vous avez besoin d’un état partagé, nommez-le honnêtement et documentez ses invariants. La clarté n’est pas éviter la complexité — c’est la placer là où le lecteur s’y attend. Pour en savoir plus sur le maintien de ces frontières lors des changements, voir /blog/refactoring-as-a-habit.

Commentaires et documentation sans le bruit

Le « goût » de Kernighan se manifeste dans la manière de commenter : l’objectif n’est pas d’annoter chaque ligne, mais de réduire la confusion future. Le meilleur commentaire est celui qui empêche une mauvaise hypothèse — surtout quand le code est correct mais surprenant.

Expliquez pourquoi, pas quoi

Un commentaire qui répète le code (« incrémente i ») ajoute du bruit et apprend aux lecteurs à ignorer les commentaires. Les commentaires utiles expliquent l’intention, les compromis ou les contraintes qui ne sont pas évidents dans la syntaxe.

# Bad: says what the code already says
retry_count += 1

# Good: explains why the retry is bounded
retry_count += 1  # Avoids throttling bans on repeated failures

Si vous êtes tenté d’écrire des commentaires « quoi », c’est souvent le signe que le code devrait être plus clair (meilleurs noms, fonction plus petite, flux de contrôle plus simple). Laissez le code porter les faits ; laissez les commentaires porter le raisonnement.

Gardez les commentaires exacts (ou supprimez-les)

Rien n’affecte la confiance plus vite qu’un commentaire obsolète. Si un commentaire est optionnel, il dérivera avec le temps ; s’il est faux, il devient une source active de bugs.

Une habitude pratique : traitez la mise à jour des commentaires comme faisant partie du changement, pas comme un « bonus ». Lors des revues, il est légitime de demander : Est-ce que ce commentaire correspond encore au comportement ? Sinon, mettez-le à jour ou supprimez-le. « Pas de commentaire » vaut mieux qu’un « mauvais commentaire ».

Placez les explications longues là où on les cherche

Les commentaires inline servent pour les surprises locales. Les guidances plus larges doivent aller dans des docstrings, README ou notes développeur — surtout pour :

• les API publiques (ce sur quoi les appelants peuvent compter)
• les invariants délicats (ordre, timing, hypothèses de concurrence)
• les contraintes (pourquoi cet algorithme, limite ou dépendance a été choisi)

Un bon docstring indique comment utiliser correctement la fonction et quelles erreurs attendre, sans narrer l’implémentation. Une courte note dans /docs ou README peut capturer l’histoire « pourquoi nous avons fait ainsi » pour qu’elle survive aux refactors.

La victoire discrète : moins de commentaires, mais chacun doit le mériter.

Clarté sous stress : gestion des erreurs et cas limites

La plupart du code semble « correct » sur le happy path. Le vrai test du goût, c’est ce qui se passe quand les entrées manquent, les services timeoutent, ou un utilisateur fait quelque chose d’inattendu. Sous stress, le code malin a tendance à cacher la vérité. Le code clair rend l’échec évident — et récupérable.

Écrivez des erreurs pour des humains

Les messages d’erreur font partie de votre produit et de votre flux de debug. Rédigez-les comme si la personne suivante qui les lirait était fatiguée et en astreinte.

Incluez :

• Ce qui s’est passé (« Impossible d’enregistrer la facture »)
• Pourquoi cela s’est produit (la cause validée, pas une supposition)
• Que faire ensuite (« Vérifiez votre connexion réseau » / « Contactez le support avec requestId »)

Si vous avez du logging, ajoutez du contexte structuré (comme requestId, userId, ou invoiceId) pour rendre le message exploitable sans fouiller d’autres données.

Gérez explicitement les cas limites (quand ça aide la compréhension)

Il y a une tentation à « tout gérer » avec un one-liner malin ou un catch-all générique. Le bon goût, c’est de choisir les quelques cas limites qui comptent et de les rendre visibles.

Par exemple, une branche explicite pour « entrée vide » ou « non trouvé » se lit souvent mieux qu’une chaîne de transformations qui produit implicitement null au milieu. Quand un cas spécial est important, nommez-le et placez-le en évidence.

Préférez des types de retour prévisibles et des chemins d’échec simples

Mélanger les formes de retour (parfois un objet, parfois une string, parfois false) contraint le lecteur à maintenir un arbre de décisions mental. Préférez des patterns qui restent cohérents :

• Retournez le même « type » de valeur à chaque fois (par ex. toujours un objet résultat)
• Utilisez les exceptions avec parcimonie et cohérence (seulement pour des échecs vraiment exceptionnels)
• Gardez les chemins d’échec proches de l’endroit où l’erreur survient, avec des retours précoces quand ils réduisent l’imbrication

Une gestion claire des échecs réduit la surprise — et la surprise est là où naissent bugs et alertes nocturnes.

Cohérence : guides de style, linters et accords d’équipe

La clarté ne concerne pas seulement ce que vous vouliez dire en écrivant le code. Elle concerne ce que la prochaine personne s’attend à voir en ouvrant un fichier à 16h55. La cohérence transforme la « lecture du code » en reconnaissance de patterns — moins de surprises, moins de malentendus, moins de débats qui recommencent à chaque sprint.

Un guide de style léger évite de répéter les mêmes arguments

Un bon guide d’équipe est court, spécifique et pragmatique. Il n’essaie pas d’encoder chaque préférence ; il tranche les questions récurrentes : conventions de nommage, structure des fichiers, patterns de gestion d’erreur, et ce que signifie « terminé » pour les tests.

La vraie valeur est sociale : il empêche la même discussion de se rejouer à chaque nouvelle PR. Quand quelque chose est écrit, les revues basculent de « je préfère X » à « nous avons convenu de X (et voici pourquoi) ». Gardez-le vivant et facile à trouver — de nombreuses équipes le placent dans le repo (par exemple, /docs/style-guide.md) pour qu’il soit proche du code.

Laissez les outils gérer les règles mécaniques

Utilisez formatters et linters pour tout ce qui est mesurable et ennuyeux :

• Formatage (indentation, sauts de ligne, ordre des imports)
• Pièges évidents (variables inutilisées, code inatteignable)
• Vérifications de cohérence simples (style des quotes, virgules finales)

Cela libère les humains pour se concentrer sur le sens : nommage, forme des API, cas limites, et correspondance du code avec l’intention.

Les règles manuelles restent importantes quand elles décrivent des choix de conception — par ex. « Préférez les retours précoces pour réduire l’imbrication » ou « Une entrée publique par module ». Les outils ne peuvent pas juger pleinement ces aspects.

Définissez des exceptions (pour qu’elles ne deviennent pas des échappatoires)

Parfois la complexité se justifie : budget de performance serré, contraintes embarquées, concurrence délicate, ou comportement spécifique à une plateforme. L’accord devrait être : les exceptions sont permises, mais explicites.

Une norme simple aide : documenter le compromis dans un court commentaire, ajouter un micro-benchmark ou une mesure quand la performance est invoquée, et isoler le code complexe derrière une interface claire pour que la majeure partie du code reste lisible.

Revues de code qui enseignent le goût au lieu de le policer

Une bonne revue devrait ressembler moins à une inspection et davantage à une leçon courte et ciblée sur le « bon goût ». Kernighan n’affirme pas que le code malin soit diabolique — il dit que la débrouillardise est coûteuse quand d’autres doivent vivre avec. Les revues sont l’endroit où ces compromis deviennent visibles et où l’équipe peut choisir la clarté volontairement.

Relisez la lisibilité d’abord (avant les exploits de performance)

Commencez par vous demander : « Un collègue peut-il comprendre ceci en une passe ? » Cela signifie généralement regarder les noms, la structure, les tests et le comportement avant de plonger dans les micro-optimisations.

Si le code est correct mais difficile à lire, traitez la lisibilité comme un vrai défaut. Suggérez de renommer des variables pour refléter l’intention, d’extraire des fonctions longues, de simplifier le flux de contrôle, ou d’ajouter un petit test montrant le comportement attendu. Une revue qui détecte « ça marche, mais je ne vois pas pourquoi » évite des semaines de confusion future.

Un ordre pratique qui fonctionne bien :

• Comportement : le changement fait-il ce qu’il prétend ?
• Tests : les tests expliquent-ils l’intention et couvrent-ils les cas limites ?
• Structure : la logique est-elle organisée pour que le lecteur la suive ?
• Noms : les noms correspondent-ils au domaine et réduisent-ils l’effort mental ?

Posez des questions, proposez des suggestions (évitez les pièges)

Les revues dérapent quand le feedback ressemble à un concours de points. Plutôt que « Pourquoi as-tu fait ça ? », essayez :

• « Pourrions-nous renommer ceci pour mieux refléter ce que c’est ? »
• « Un retour précoce ne rendrait-il pas cela plus lisible ? »
• « Que penses-tu d’extraire ceci en helper pour que le chemin principal se lise de haut en bas ? »

Les questions invitent à la collaboration et font souvent surgir des contraintes que vous ignoriez. Les suggestions indiquent une direction sans impliquer d’incompétence. Ce ton est la façon dont le « goût » se répand dans une équipe.

Intégrez la clarté au processus

Si vous voulez une lisibilité cohérente, ne comptez pas sur l’humeur du reviewer. Ajoutez quelques « checks de clarté » à votre template de revue et à la définition de fait. Gardez-les courts et précis :

• « Un nouveau collègue peut-il expliquer cette fonction après l’avoir lue une fois ? »
• « Y a-t-il un happy path clair et une gestion d’erreur claire ? »
• « Les tests se lisent-ils comme des exemples de comportement attendu ? »

Avec le temps, cela transforme les revues de code de la police à l’enseignement du jugement — exactement la discipline quotidienne que Kernighan prônait.

Note sur le codage assisté par IA : gardez les mêmes standards

Les outils LLM peuvent produire du code fonctionnel rapidement, mais « ça marche » n’est pas la barre indiquée par Kernighan — ça communique l’est. Si votre équipe utilise un workflow de génération (par ex. construire des fonctionnalités via chat et itérer sur du code généré), traitez la lisibilité comme un critère d’acceptation de première classe.

Sur des plateformes comme Koder.ai, où vous pouvez générer des frontends React, des backends Go et des apps Flutter depuis une conversation (et exporter le code source ensuite), les mêmes habitudes de goût s’appliquent :

• demandez une structure de module claire et des noms qui révèlent l’intention, pas seulement « fais-le marcher »
• exigez des chemins d’erreur explicites et des formes de retour cohérentes
• utilisez des snapshots/rollback pour itérer en toute sécurité tout en refactorisant vers la clarté

La vitesse est vraiment utile quand le résultat reste facile à relire, maintenir et étendre par des humains.

Refactoriser comme habitude : garder le code clair dans le temps

La clarté n’est pas un état que l’on « atteint » une fois. Le code reste lisible seulement si vous le poussez régulièrement vers une langue plus simple à mesure que les exigences changent. La sensibilité de Kernighan s’intègre ici : préférez des améliorations régulières et compréhensibles plutôt que des réécritures héroïques ou des one-liners « intelligents » qui impressionnent aujourd’hui et embrouillent le mois prochain.

Refactorisez par petites étapes sûres (les tests comme garde-fous)

Le refactor le plus sûr est ennuyeux : de petits changements qui conservent un comportement identique. Si vous avez des tests, exécutez-les après chaque étape. Sinon, ajoutez quelques vérifications ciblées autour de la zone que vous touchez — pensez-les comme des garde-fous temporaires pour améliorer la structure sans peur.

Un rythme pratique :

• Faites un changement (renommer, extraire une fonction, simplifier une condition)
• Lancez les tests (ou une vérification manuelle ciblée)
• Committez

Les petits commits rendent aussi la revue plus simple : les collègues peuvent juger l’intention, pas chercher des effets de bord.

Remplacez la débrouillardise progressivement

Vous n’avez pas à purger toutes les constructions « malines » en une fois. Quand vous touchez le code pour une fonctionnalité ou un bug, échangez les raccourcis astucieux contre des équivalents simples :

• regrouper une logique booléenne en helpers nommés
• remplacer des ternaires imbriqués par des blocs if/else clairs
• substituer des « nombres magiques » par des constantes nommées

C’est ainsi que la clarté gagne dans les équipes réelles : un hotspot amélioré à la fois, exactement là où les gens travaillent déjà.

Suivez la dette de refactorisation : nettoyer maintenant vs planifier

Toutes les améliorations ne sont pas urgentes. Une règle utile : refactorez maintenant quand le code change activement, est fréquemment mal compris, ou est susceptible de causer des bugs. Planifiez plus tard quand il est stable et isolé.

Rendez la dette de refactor visible : laissez un court TODO avec le contexte, ou ajoutez un ticket qui décrit la douleur (« difficile d’ajouter de nouveaux moyens de paiement ; la fonction fait 5 jobs »). Ainsi, vous décidez délibérément plutôt que de laisser un code confus devenir la taxe permanente de l’équipe.

Une checklist pratique de clarté (et idées simples d’avant/après)

Si vous voulez que le « bon goût » apparaisse régulièrement, facilitez sa pratique. Voici une checklist légère à réutiliser en planification, codage et revue — assez courte pour se souvenir, assez précise pour agir.

Une checklist de clarté que votre équipe peut répéter

• Nommage : chaque nom dit-il ce que c’est et à quoi ça sert ? Préférez les mots de domaine aux blagues internes. Évitez les abréviations à moins qu’elles ne soient standard.
• Flux : peut-on lire la fonction de haut en bas sans rebrousser chemin ? Gardez le « happy path » en évidence ; poussez les cas exceptionnels sur les bords.
• Modules : chaque fichier/classe a-t-il un seul rôle ? Les dépendances sont-elles évidentes ? Si vous deviez le supprimer, sauriez-vous ce qui casserait ?
• Erreurs : les échecs sont-ils gérés proches du lieu d’occurrence ? Les messages sont-ils exploitables (quoi, où, quoi faire ensuite) ?
• Tests : les tests se lisent-ils comme des exemples d’utilisation réelle ? Couvre-t-ils les cas limite qui vous ont déjà posé problème ?

Idées « avant/après » (pas besoin de syntaxe fancy)

Avant : process(data) fait validation, parsing, sauvegarde et logging en un seul endroit.

Après : Scindez en validateInput, parseOrder, saveOrder, logResult. La fonction principale devient un plan lisible.

Avant : if not valid then return false répété cinq fois.

Après : Une section de garde upfront (ou une fonction de validation) qui retourne une liste claire de problèmes.

Avant : x, tmp, flag2, doThing().

Après : retryCount, draftInvoice, isEligibleForRefund, sendReminderEmail().

Avant : Une boucle avec trois cas spéciaux cachés au milieu.

Après : Gérez d’abord les cas spéciaux (ou extrayez des helpers), puis exécutez la boucle simple.

Un défi d’équipe d’une semaine

Choisissez une amélioration à adopter cette semaine : « pas de nouvelles abréviations », « happy path first », « extraire un helper par PR », ou « chaque message d’erreur inclut les étapes suivantes ». Suivez-la pendant sept jours, puis gardez ce qui a réellement facilité la lecture.