Comment nommer une fonction pour que ce soit clair et concis ?

[Joseph23]

Salut tout le monde, je me pose une question depuis quelques jours suite à un truc qui m’est arrivé au boulot. J’étais en train de refactoriser une vieille portion de code pour la rendre plus maintenable, et je me suis surpris à hésiter longtemps sur le nom à donner à une nouvelle fonction qui regroupe plusieurs étapes de validation. D’un côté, je voulais quelque chose de très précis qui décrit exactement ce qu’elle fait, mais de l’autre, ça donnait un nom super long et un peu lourd. Vous aussi, parfois, vous passez trop de temps sur des détails comme ça ? Je me demande si c’est une perte de temps ou si, au contraire, ce genre de réflexion sur la clarté du code est toujours utile à long terme.

[Nora59]

Pour moi le nommage est une promesse de clarté plus que de précision absolue. Quand une fonction regroupe plusieurs validations, mieux vaut viser un nom qui indique l’intention sans être une liste exhaustive. Par exemple, plutôt que 'validerToutesLesEntréesEtRègles', on peut écrire 'validerEntrées' ou 'validerEtRegrouper', l’idée étant que le lecteur saisisse rapidement ce qui se passe. Le vrai défi, c’est que la clarté peut faire gonfler le nom; trouver l’équilibre entre précision et concision, c’est un exercice de clarté en soi.

[AndrewJ]

Oui, parfois je me perds dans le nom, et je me dis que la clarté peut attendre. Mais le vrai dilemme, c’est que chaque mot compte: un nom lourd peut décourager, un nom trop vague peut tromper. Et si on choisissait un nom qui rappelle le flux plutôt que chaque étape ? clarté et lisibilité se nourrissent, même si ça demande quelques compromis.

[Hannah64]

Je suis passé par là: j’ai mis un nom qui me paraissait clair sur le moment, puis j’ai vu qu’il n’évoquait pas vraiment ce que le code fait au fil du temps. La clarté vient parfois plus du contexte et des tests que d’un nom accrocheur. Peut-être que l’essentiel est que les autres devs puissent comprendre sans devoir relire le doc.

[Steven12]

Ouais, nommer, c’est galère, surtout quand on veut éviter un roman. J’ai souvent un compromis: un nom qui parle du but général, sans énumérer chaque étape. Clarté sans en faire un chapitre sur les noms.

[Savannah_H]

Les lecteurs du repo attendent une clarté qui ne trahit pas le coût mental: le nom peut influencer le chemin de lecture plus que le code lui‑même. Le nommage est aussi lié aux habitudes du genre et aux attentes des contributeurs: parfois il vaut mieux viser le plus lisible plutôt que le plus exact. clarté.

[EvelynW]

Si j’ai bien compris, ton souci est de savoir si le coût cognitif du nom exact vaut le bénéfice en lisibilité sur le long terme; on cherche un équilibre entre dire ce que fait la fonction et ne pas alourdir le code. Le nommage influence la perception du flux de validation et la tolérance aux changements, et il est possible que ce soit plus un art qu’une science.