14 points par GN⁺ 2025-12-12 | 7 commentaires | Partager sur WhatsApp
  • Dans la culture moderne du développement logiciel, les noms de projets et de bibliothèques sont de plus en plus remplis de mots arbitraires sans rapport avec leur fonction
  • Autrefois, des noms comme grep, awk, sed, FORTRAN, COBOL décrivaient directement une fonction ou un objectif, mais aujourd’hui les appellations dénuées de sens prolifèrent
  • Cette tendance s’est accélérée avec l’essor de GitHub et de la culture startup, jusqu’à rompre complètement le lien entre le nom et la fonction
  • Le coût de compréhension et la charge cognitive augmentent, obligeant les développeurs à multiplier les recherches inutiles pour comprendre le rôle de chaque outil
  • L’article appelle à rétablir des conventions de nommage claires et centrées sur la fonction, et souligne que pour les outils techniques, la clarté et le professionnalisme doivent primer sur la marque

L’évolution des pratiques de nommage dans le logiciel

  • Lors d’une conférence EmacsConf en 2022, Richard Stallman a souligné l’importance des « noms faciles à mémoriser » et insisté sur le fait qu’un nom de package devrait révéler ce qu’il fait
    • L’écosystème Emacs a traditionnellement conservé des conventions de nommage basées sur la fonction, comme dired (éditeur de répertoires) ou eshell (shell Emacs)
  • Pourtant, les développeurs modernes ont tendance à donner à leurs outils des noms tirés de noms communs aléatoires, créatures mythologiques ou personnages fictifs
    • Dans d’autres domaines techniques, ce comportement serait considéré comme un manque de professionnalisme

Le problème des noms sans signification

  • Par exemple, des noms d’outils comme Viper, Cobra, Melody, Casbin ou Asynq ne permettent absolument pas de deviner leur fonction
    • L’auteur évoque même une expérience où il a dû faire une recherche pour comprendre l’explication d’infrastructure donnée par un ami
  • Dans d’autres branches de l’ingénierie, les noms décrivent la structure ou la fonction
    • Ex. : Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve rendent clairement visible leur forme ou leur rôle
  • En chimie, des systèmes comme la nomenclature IUPAC imposent qu’un nom désigne précisément un seul objet
    • Ex. : 2,2,4-trimethylpentane désigne une seule molécule ; on ne l’appelle pas arbitrairement « Steve »

Les règles d’hier et la rupture actuelle

  • Dans les années 1980, des abréviations fonctionnelles comme grep, awk, sed, cat, diff dominaient
    • Les noms de langages comme FORTRAN, COBOL, BASIC, SQL, Lisp reflétaient eux aussi leur objectif
  • Depuis les années 2010, la diffusion des noms dépourvus de sens s’est accélérée
    • Certains, comme MongoDB, conservaient encore un lien fonctionnel ou étymologique, mais avec GitHub et la culture startup, les noms arbitraires se sont multipliés
    • L’article y voit notamment une imitation de réussites orientées marque, comme Google

Coût cognitif et baisse d’efficacité

  • Un nom comme libsodium rend difficile l’inférence de sa fonction et pousse le développeur à multiplier les changements de contexte
    • Du temps est inutilement perdu à se demander : « pourquoi sodium ? »
  • Plus un projet a de dépendances, plus cette taxe cognitive (cognitive tax) s’accumule
    • Cela finit par réduire la productivité des développeurs
  • L’auteur souligne qu’en traitant une phrase comme « Viper, Cobra, Melody… », des ressources mentales sont gaspillées à interpréter des jetons sans signification

Réponses aux objections courantes

  • « Un nom facile à retenir aide le marketing » → les outils pour développeurs ne sont pas des produits grand public, et la clarté fonctionnelle est plus importante
  • « Les noms descriptifs sont ennuyeux » → cet ennui est un prix acceptable pour la clarté ; les instruments chirurgicaux sont ennuyeux aussi, mais précis
  • « C’est juste pour s’amuser » → tous les utilisateurs paient le prix de cet “amusement”, ce qui se traduit par une perte de temps à l’échelle du secteur
  • « Tous les bons noms sont déjà pris » → les espaces de noms, préfixes et mots composés permettent de contourner le problème ; au minimum, il faut choisir un nom lié à la fonction

Quelle direction pour la suite ?

  • Le problème est présenté non comme une intention malveillante, mais comme le résultat d’une évolution culturelle
    • À mesure que la programmation est passée d’un univers centré sur l’entreprise à un univers plus communautaire, les normes sociales se sont affaiblies
  • La solution serait une restauration culturelle des conventions de nommage
    • Plutôt qu’une régulation, l’amélioration devrait passer par le retour du professionnalisme, la formation et la pression sociale
  • Le nom des bibliothèques devrait refléter leur fonction, quitte à accepter des mots composés et des formulations longues
    • Par exemple, http-request-validator est bien plus clair que zephyr
  • Il faut séparer la mascotte du nom
    • Par exemple, PostgreSQL utilise Slonik comme mascotte en forme d’éléphant, mais son nom lui-même conserve une signification fonctionnelle
  • S’il ne s’agit pas d’un produit grand public où le branding est crucial, il faut faire passer la clarté et le professionnalisme avant tout
    • Avant de choisir « le nom de son personnage d’anime préféré », il faudrait se demander : « un ingénieur civil donnerait-il ce genre de nom à un système de pont ? »
  • En conclusion, il faut mettre fin à la prolifération des noms dépourvus de sens et revenir à un langage professionnel clair
    • La clarté n’est pas de l’ennui, c’est une marque de respect pour le temps et les ressources cognitives des utilisateurs

7 commentaires

 
roxie 2025-12-15

S’il n’y avait pas eu d’exemples, ça aurait sans doute augmenté le pouvoir de conviction de 10 %..

 
kandk 2025-12-15

Je suis plutôt d’accord dans une certaine mesure, mais on dirait surtout qu’ils ne veulent pas subir le stress de devoir trouver un nom.

 
qpolsa95 2025-12-13

Tous les noms valables sont déjà utilisés par quelqu’un.

 
GN⁺ 2025-12-12
Réactions sur Hacker News
  • La version GNU de Yacc s’appelle Bison. Pine était l’acronyme de « Pine Is Not Elm », et UNIX vient de UNICS, un jeu de mots sur MULTICS. On ne sait pas trop ce que veut dire dd, nano est un clone de pico, et Postfix est un mot-valise entre « post » et « bug fix ». C++ est la version incrémentée de C, C est le successeur de B, et B est le successeur de BCPL. En réalité, les développeurs n’ont pas « perdu la philosophie du naming » : ils ne l’ont jamais vraiment eue. À l’inverse, des projets modernes comme Clang, LLDB, jq, fzf ou loc sont de bons exemples de noms réussis. mise-en-place est aussi une métaphore parfaite des fonctions de mise

    • dd vient de l’instruction DD de JCL. À l’origine, le nom vient de la manière de décrire les fichiers sur les mainframes IBM, et la commande dd d’UNIX a été créée pour échanger des fichiers avec ces mainframes. C’est pour cela qu’elle utilise une syntaxe en clé=valeur, peu typique d’UNIX
    • dd a aussi longtemps été surnommé, pour rire, « delete disk » ou « destroy data », parce qu’on l’utilisait souvent pour écraser des blocs de disque
    • C++ désigne l’opérateur d’incrémentation postfixé de C. C’est donc une métaphore parfaite : la valeur est celle de C, puis elle est incrémentée après lecture
    • GNU et Emacs sont aussi des acronymes récursifs. Perl, Python, Java, Go, Pascal, Git, Mercurial, CVS, etc. ont eux aussi des noms aux significations très diverses. Au final, le débat sur les noms est une agitation sans grand intérêt
    • Back Orifice 2000 avait un nom qui indiquait très clairement ce qu’il faisait, mais ce n’était pas le cas de BitchX
  • Les commandes UNIX comme grep, awk, sed, cat ou diff avaient des noms fonctionnels ou systématiques, mais en réalité seul diff est à peu près devinable intuitivement. Dire qu’awk est un bon nom est exagéré

    • Si ces noms paraissent naturels, c’est surtout une illusion d’habitude. Aujourd’hui, avec l’immense quantité d’utilitaires et de bibliothèques, la différenciation des noms est devenue indispensable
    • Libiberty était l’un des noms les plus drôles. Il a été choisi pour qu’on puisse le lier avec l’option -liberty
    • cat ne vient pas de concatenate mais de catenate. Le préfixe « con » était redondant, donc supprimé. C’est un exemple intéressant aussi du point de vue linguistique
    • awk, sed et cat ne sont pas tant de bons noms que des noms devenus familiers. grep, en revanche, sonne presque comme une onomatopée, avec l’idée d’« attraper » un motif
    • Comme le jargon professionnel propre à chaque industrie, ces sigles et abréviations deviennent naturels une fois appris. À l’époque, l’efficacité de frappe comptait beaucoup, donc la différence entre cat et concat pouvait réellement jouer sur la productivité
  • À l’affirmation selon laquelle « dans la tech, ce genre de nommage est un suicide professionnel », certains répondent en citant la liste des noms de code du département de la Défense américain, où l’on trouve au contraire beaucoup de noms volontairement opaques. Le barrage Hoover s’appelait d’abord Boulder Canyon Project, sans que le nom décrive vraiment sa fonction. Reitzlib serait-il vraiment meilleur que Requests ? Au final, tout dépend du contexte

    • La chimie aussi regorge de noms amusants. On y trouve par exemple des algorithmes ou des paquets comme SHAKE, RATTLE, CHARMm ou Amber. Les noms mignons sont encore plus fréquents en biologie
    • La météorologie n’y échappe pas non plus. Le phénomène auroral STEVE en est un bon exemple
    • Les noms de code militaires sont délibérément aléatoires afin d’en masquer le sens, et les projets internes d’entreprise emploient parfois la même méthode
    • La biologie a elle aussi des noms comme Sonic hedgehog protein
    • L’astronomie est particulièrement connue pour ses pires acronymes. On peut en voir des exemples sur ce lien
  • Des noms comme awk ne sont pas réellement de bons noms. Ce sont juste les initiales des auteurs, et ils ne transmettent rien sur la fonction. Aujourd’hui, avec l’autocomplétion par tabulation, il n’y a plus vraiment besoin de raccourcir autant

  • Je suis assez d’accord avec ce texte de réponse. Les identifiants externes changent de sens avec le temps, donc les noms censés être parfaitement descriptifs vieillissent mal. En plus, il existe déjà trop de noms du type « X Manager » ou « X Service », ce qui les rend difficiles à distinguer

    • J’aime les noms ingénieux. Si nommer est difficile, c’est souvent le signe que le concept n’est pas encore clair. Le nom idéal paraît étrange au début, puis devient mémorable quand on en comprend le sens. Le fait que l’équipe A/B testing de Spotify se soit appelée « ABBA » en est un excellent exemple
    • Bien sûr, cela dépend de l’objectif. Mais se concentrer sur une seule tâche et la refléter dans le nom reste aussi un bon principe
  • J’ai travaillé comme ingénieur en calibration moteur chez un OEM automobile, et toutes les variables ainsi que toutes les fonctions étaient en abréviations. Le premier mois était épuisant au point d’en avoir la tête qui explose. Un collègue m’a finalement dit que c’était comme apprendre une nouvelle langue, et c’était exactement ça. Autrement dit, multiplier les noms techniques ne réduit pas forcément la charge cognitive

    • C’est pareil dans les télécoms mobiles. Essayer de mémoriser tous les acronymes n’a pas de fin. Par exemple, AP peut vouloir dire Application Processor ou Access Point selon le contexte. Mais c’est plus court que MSISDN, donc on n’a pas vraiment le choix
    • Si l’on regarde cette vidéo sur l’examen de qualification des taxis londoniens, on explique que la fatigue d’apprentissage est telle qu’elle modifie réellement la structure du cerveau. Les systèmes de dénomination complexes entraînent donc intrinsèquement une charge cognitive
  • J’ai du mal à être d’accord avec l’idée que « les noms fonctionnels valent mieux que le marketing ». Les noms basés sur la fonction finissent par produire un océan sans fin d’acronymes. On se retrouve à confondre ABDC et ADBC

    • J’ai aussi travaillé dans ce genre d’organisation, et au bout du compte on se retrouve avec des noms comme CoreMainHttp et MainHttpCore, voire avec plusieurs API différentes portant le même nom. Des noms d’anciennes équipes finissent aussi par survivre dans des choses comme « DataOrgUtils ». Au final, même les noms mignons convergent de façon répétitive : Phoenix, Keymaster, Simpsons, Star Wars et d’autres mèmes culturels reviennent sans cesse
    • L’auteur oublie que les outils qui nous entourent ont survécu à la concurrence. Un nom mémorable a aidé à survivre
  • Je suis surpris de voir ce genre de billet sur HN. Prendre des noms comme awk comme exemple pour affirmer qu’« on a perdu l’essence du naming » est contradictoire. Au fond, cela ressemble surtout à une aversion personnelle pour les noms mignons. D’ailleurs, ce commentaire a été écrit dans Firefox — et son nom ne permet pas non plus de deviner que c’est un navigateur web

    • Même des noms comme awk avaient une certaine signification à leur époque. Les logiciels modernes s’adressent à un public plus large, donc il faut un équilibre entre professionnalisme et fantaisie. Je n’ai rien contre les noms mignons, mais il faut simplement être prudent dans un contexte professionnel. (Ce commentaire est envoyé avec msmtp — un client SMTP dont le nom décrit effectivement la fonction)
  • À l’idée selon laquelle « les noms descriptifs sont ennuyeux », on peut répondre que les instruments de salle d’opération portent eux aussi souvent des noms de personnes. Adson, Allis, Babcock, Kocher : aucun de ces noms ne décrit la fonction. C’est l’habitude qui leur donne du sens. awk n’est pas terrible, mais diff est un exemple plus acceptable

    • Quiconque s’est déjà fait poser une broche de Kirchner comprendra
  • À l’affirmation selon laquelle « notre domaine ressemble à un zoo de noms communs choisis au hasard », je réponds que j’aime les noms amusants. Mon projet Wimsey est une bibliothèque de tests de données, mais son nom ne le dit pas. Malgré cela, j’aime des noms comme Python, Cron ou Zellij, qui portent de l’affection et de l’humour. La technique reste une création humaine, et elle doit garder une part de plaisir. « brown-dog-2 » est moins humain que « cookie »

    • Mais un nom comme « data-testing-library » perd tout son sens dès qu’il en existe un deuxième
    • Des noms structurés comme Project.Parser.Pcapng en .NET sont utiles à l’intérieur d’un projet, mais hors de leur contexte indépendant, ils ne servent pas à grand-chose
    • À l’inverse, certaines personnes trouvent du plaisir dans le professionnalisme lui-même et voient les noms mignons comme une distraction. Selon cette vision, la vraie joie vient de la satisfaction du travail bien fait, du sens de l’artisanat
 
epdlemflaj 2025-12-13

Même Awk n’est pas vraiment un nom basé sur la fonctionnalité...

 
khris 2025-12-13

Quelqu’un sait ce que signifie emacs ? Il a bien un sens, mais avec un nom en acronymes on ne peut pas le deviner au premier coup d’œil, alors que c’est censé être un nom… Et désormais, il y a aussi bien trop de projets pour les nommer uniquement d’après leur fonction.

 
cgl00 2025-12-13

À voir qu’il rejette la faute sur GitHub, on dirait juste une critique à la RMS mdr