Nommage en Anglais ou Francais ou Franglais
Au démarrage d'un projet et à des fins de qualité de développement l'équipe doit s'imposer des conventions et des bonnes pratiques à respecter tout au long de ce projet. Il existe de nombreuses bonnes pratiques admises. Par exemple pour les nommages des variables et attributs on utilise le Camel Case, comme le suggère les conventions de nommage Sun.
Cependant, à la question "dois je utiliser l'anglais ou le français pour nommer mes classes et mes méthodes?", il n'y a pas encore de consensus admis. Il y a différentes possibilités :
- Le tout en anglais
- Le tout en français
- Le franglais
Le tout en anglais
Généralement c'est le choix indiscutable si vous travaillez avec des équipiers anglophones, développeurs ou fonctionnels. Cependant cela est plus discutable lorsque l'équipe métier travaille en français.
Exemple
Défauts
La traduction de terme métier français en anglais introduit de nombreux problèmes :
- Mauvaise traduction.
- Ex: Conducteur ne se traduit pas Conductor mais Driver. Conductor signifie en français Contrôleur. Ce sont des faux-amis.
- Traduction dupliquée, il existe différentes traductions acceptables pour un même terme métier. Plus tard les développeurs vont se demander pourquoi deux traductions? parle-t-on de la même chose?
- Ex : Travail en anglais peut se traduire par Employ, Job
- Traduction vague, mauvaise traduction automatique.
- gameOfData => jeu de données, la traduction mot à mot est bonne mais jeu de données se traduit setOfData.
- etc ... il faut donc créer un lexique de traduction des termes métiers. Cela demande encore plus de travail. Ce n'est pas très réaliste.
Avantages
- Généralement, les développeurs ont l'habitude de manipuler l'anglais mais seulement dans un contexte technique et pas fonctionnel
- Possible avec des équipes polyglottes, l'anglais reste la langue de référence
- Indispensable, pour les projets internationaux et Open Source
Le tout en français
FBI, Fausse Bonne Idée.
Exemple
On constate rapidement qu'il n'est pas naturel, pour un développeur, de traduire get et set. Il en est de même pour un certain nombre d'artefacts qui sont en anglais :
- Les patterns : Singleton, Repository.
- Les qualifieurs de classe : Repository, Service, DAO.
- Les qualifieurs de méthode : find, set, get.
- etc ...
Défauts
- Les frameworks ne supportent pas toujours le français l'exemple le plus connu est la convention java bean.
Avantages
- Plus de problèmes de traduction.
Le Franglais
Quitte à se mettre à dos Jacques Toubon, il me semble que le meilleur compromis est le franglais. Les artefacts métiers sont nommés en français. Les artefacts techniques sont nommés en anglais.
Exemple
Dans l'exemple suivant on mélange à la fois des termes métiers en français, objets et règles métiers, et des termes techniques en anglais, pattern specification
public boolean isSatisfiedBy(Panier panier) {
for (Produit produit : panier.getProduits()) {
if ( ! (produit instanceof Abricot
|| produit instanceof Carotte
|| produit instanceof Citrouille
|| produit instanceof Mandarine
|| produit instanceof Orange)) {
return false;
}
}
return true;
}
}
Défauts
- Au premier abord, il peut être choquant de lire du code à moitié de l'anglais à moitié du français. On s'habitue, il suffit juste de définir la bonne frontière. Les termes métiers sont en français, le reste en anglais.
Avantages
- On est le plus explicite et le plus précis possible dans le choix de nos noms de classes, méthodes, packages et variables, dans sa langue maternelle
- Les fonctionnels et les développeurs ont un langage commun (en DDD c'est l'ubiquitous language). Pour un langage commun il faut donc une langue commune, idéalement c'est la langue maternelle parlée par les fonctionnels.
Conclusion
Dans le cas de projets internationaux ou si le fonctionnel travaille en anglais il est indispensable d'utiliser l'anglais pour le nommage des artefacts du code source.
Par contre si le fonctionnel travaille en français, alors le choix n'est plus aussi tranché.
Pour le nommage des artefacts, il faut avoir quelques idées directrices en tête :
- Être précis et explicite (i.e. efficace) dans le choix des noms des artefacts.
- Idéalement, être auto-documenté. 5 lignes de javadoc pour expliquer le pourquoi du comment du choix de la traduction est superflu.
- Respecter ces règles est un grand pas en avant pour la maintenance de l'application.
- Une classe mal nommée introduit une dette technique.
- Ne pas hésiter à faire différents refactorings pour trouver le meilleur nom.
- Si vous ne trouvez pas un nom satisfaisant, parlez en au reste de l'équipe de développement et fonctionnelle.
Le choix de langage de nommage n'est pas un détail. Dans un contexte de projet entièrement francophone, il m'est arrivé de choisir le tout en anglais. Mais au fil des mois et des incompréhensions dues aux traductions, nous avons de plus en plus regretté ce choix. Pour ce type de projet, je choisirai maintenant le franglais. De plus, cela permet d'être plus près des préconisations du Domain Driven Design, afin de construire l'ubiquitous language avec la langue maternelle des fonctionnels.
Billets sur le même thème :
- XP Day France 2009 – Qualité du code source et l’intégration continue
- XP Day – Qualité du code source et intégration continue
- DDD – La conception qui lie le fonctionnel et le code
- Le pattern Specification pour la gestion de vos règles métier
- Traduction du Maven Definitive Guide, première relecture publique
Le franglais a quand même un certain nombre de limites. Ainsi, la frontière entre les termes techniques et les termes fonctionnels n'est pas toujours bien établie.
La règle n'est pas claire pour les choix autres que noms d'entités. Exemple dans votre code : isSatisfiedBy marque permet de définir des règles fonctionnelles, est-ce que ça n'appartient pas au domaine fonctionnelle ? Peut-être pas, on utilise ici un pattern.
Et pour les noms de méthodes, franglais autorisé ? Ex, avec un dao :
findAllByPrenomWithEmailEmpty
findAllByPrenomAvecEmailVide
trouverTousParPrenomAvecEmailVide
...
Je pense que si l'on adopte le franglais, il faut définir des règles de nommage TRES précises en rentrant bien dans les détails. Dans le cas contraire, suivant les développeurs, les méthodes ne seront pas nommées de la même manière...
Finalement, je me demande si utiliser le franglais pour des développements pérennes ne nécessite pas autant de travail que le tout Anglais AVEC un glossaire.
Quand au fait que les Français sont globalement mauvais en Anglais, c'est malheureusement une réalité, mais ça ne peut pas faire de mal d'apprendre quelques termes de vocabulaire
. Le tout est d'avoir des référents dans l'équipe qui sachent proposer des termes valables.
Bonjour,
nous avons le même débat en interne lors de la constitution d'un framework.
On avait tranché pour l'anglais. Mais nous travaillons dans l'assurance de santé donc il s'est posé des problèmes de traduction car aucun fonctionnel ne parle pas correctement l'anglais et de plus le système de santé et son vocabulaire est bien franco-français.
Après 2 jours à se casser la tête, il nous est paru plus facile de travailler en anglais pour le technique mais tous les termes métier sont en français, en gros les noms des classes métiers et leurs attributs.
Cela donne un mélange pittoresque mais on sépare visuellement les parties techniques et fonctionnelles.
Pour ma part, c'est du franglais. Essentiellement à cause du baobab dans la main de chercher la bonne traduction pour des termes souvent tordus (et plus particulièrement les termes techniques comptables).
Concernant les noms de méthode, nous utilisons le terme anglais sur l'action (search, get, set, delete, etc.) mais le français pour le reste. Ainsi, on peut avoir des searchClientsActifs, etc.
Ayant utilisé cette technique depuis maintenant plusieurs années (dans une équipe franco-française cocorico), j'en suis particulièrement content. Tout le monde y trouve son compte.
Pareil, franglais pour mon dernier projet.
Par contre, un problème très pragmatique se présente et qui n'a pas été évoqué ici.
Ok les méthodes deviennent très compréhensible (gros avantage), en revance la longueur de celle-ci explose et il devient alors plus que recommandé d'avoir un écran large.
En plus pour peu que checkstyle limite la longueur d'une ligne...
@pronostictictic : la longueur des noms de méthode n'est pas trop problématique, pour peu que le code soit indenté correctement. Après, c'est vrai que je suis en 1600x1200. Donc, une résolution assez large.
Quant à l'inconvénient de taper de longs noms de méthodes, généralement, sur tout éditeur digne de ce nom, il y a de l'auto-complétion. Donc, pas de soucis pour du franglais. :p
C'est amusant de lire "il me semble que le meilleur compromis est le franglais", car en entretien technique chez vous il y a quelque temps on m'avait reproché d'avoir écrit un code en franglais en déclarant je cite : "Non on écrit soit en anglais, soit en français, on ne mélange pas". J'exagère un peu mais c'était à peu près ça.
Le plus important n'est-il pas de se comprendre ?
Je cite: "Conductor signifie en français Contrôleur. Ce sont des faux-amis."
Ah bon? Mr Robert n'a pas l'air d'accord...
http://www.lerobert.com/index.php?searchword=Conductor+&option=com_lr_search&Itemid=2
Avant de s'essayer au franglais faudrait peut-être commencer par le français tout court, non?
Je suis globalement d'accord avec cet article, et c'est ce que j'essaie de faire dans mes développements. Je tique un peu sur la séparation métier/reste qui déterminerait la séparation français/anglais. Après tout, il peut y avoir des frameworks métiers en anglais.
Il me semble qu'il faut insister sur le fait que la pratique du français dans le code ne vient pas d'une lubie franco-française, mais d'un effort pour comprendre et exprimer de la façon la plus claire possible ce que l'on fait, aussi bien dans le niveau purement informatique que dans notre expression du niveau métier. C'est parce que nous travaillons avec des français qu'il me semble préférable que le code soit aussi écrit en français.
Il est nécessaire que le niveau purement informatique soit aussi compris par nos interlocuteurs, même -et surtout - s'ils ne sont pas informaticiens. Du moins, que l'on fasse le maximum d'efforts en ce sens.
Concernant la place de l'anglais, il me semble que dès qu'on utilise un paquetage écrit en anglais, on utilise l'anglais, forcément. Ce n'est pas la séparation métier/autre qui compte. Et même si je fais une bibliothèque niveau technique DAO, je vois pas pourquoi je le ferais pas en français.
Je suis aussi d'accord avec le maintien des get et set. Mais je ne vois pas pourquoi on conserverait des find et autre. Le maintien des get et set vient de la pratique des beans, qui est devenu standard de fait. À ma connaissance, le seul autre terme à retenir est "listener", et peut être aussi "event", bien que l'usage de java.util.EventListener (d'ailleurs très mal nommé, je trouve, c'est l'exemple même de ce que l'anglais n'est pas toujours clair ! ) couvre normalement ce cas.
J'hésite aussi pour la conservation des patterns en anglais. Le problème des patterns est que ce sont des lieux communs ; il me semble qu'il faut les re-définir à chaque projet, sinon on croit les comprendre alors que ce n'est pas vrai.
Je trouve que même au niveau anglais les patterns ne sont pas toujours clairs. Exemple entre mille : "AbstractBeanFactoryBasedTargetSourceCreator" de Spring, et c'est loin d'être le pire... au niveau des patterns on est servis. Mais qu'est ce que peut être un Factory Abstract ? Un Factory Based ?? Based Target ?? Un Factory de Creator ou un Creator de Factory ??? Ici il me semble que l'usage de prépositions aurait rendu la signification plus claire : AbstractBeanFactoryOfBasedTargetSourceCreator, peut être.
En tous les cas merci pour cet article.
Pour moi c'est anglais total et franglais sous la contrainte.
J'ai passé trop de temps à réparer des fichiers cassés ou courir après des configurations de plugins maven, suite à des problèmes d'encodages et de caractères spéciaux. J'ai même vu des livraisons maven échouer suite à des accents dans les commentaires de commit et une erreur de génération de changelog.
En conséquence, Anglais partout comme cela pas de caractères spéciaux, sauf si la politique du client est l'utilisation du Français, mais alors pas d'accent dans les commentaires, ce qui les rend plus pénibles à lire qu'en Anglais.....
Pour maven ajouter iso-8859-15 dans la configuration du plugin compiler. Il n'y aura plus de problème d'accent.
C'est ce qui a été fait, sauf que si la moitié de l'équipe a configurer Eclipse en UTF8 et l'autre en iso... Sans parler qu'il faut le faire pour les différents types de fichiers dans Eclipse, et qu'il arrive de modifier certains fichiers de config avec un simple éditeur de texte......
Et à gérer ainsi les encodages, vous n'avez que des problèmes d'accents dans les commentaires !? Vous avez de la chance.
Il me semblerait mieux de monter une sorte de discipline dans l'équipe de développement, contrôler le contenu des fichiers de config, préciser l'encodage dans la lecture/écriture des fichiers, bases de données et autre, etc. Tout un boulot, oui, mais l'informatique est censée fonctionner aussi à Trifoullis-Les-Oies que je sache.
@hervé je suis d'accord, l'important c'est d'être compris par les autres, par le métier en premier lieu. Si le métier maitrise et utilise l'anglais au quotidien, l'anglais s'impose. Si le métier parle français au quotidien le franglais semble plus pragmatique.
Par contre je tique sur les DAO en français (des OAD ?) Pour moi la séparation français/anglais est claire : noms de classes, variables venant du métier en français, tout le reste en anglais. Car le reste c'est de l'informatique, or en informatique le standard c'est l'anglais. "paquetage" est un autre exemple, il m'a fallu quelques secondes pour comprendre de quoi il s'agissait
@christophe l'encodage pour l'anglais c'est une excuse bidon, il faut bien afficher des pages en français sur le site, donc les problèmes d'encodage on y coupe pas (mais on a l'habitude, on est nés dedans
@pfff ton lien affiche "0 résultat trouvé". par contre wordreference http://www.wordreference.com/enfr/conductor semble donner raison à l'auteur de l'article
Quel sujet passionnant, merci Xebia
@franglais : Pour les DAO c'est comme pour le reste ; dans le cas particulier de la DAO on doit exprimer d'où sortent les données ; "DAO" est un lieu commun, un truc qui n'exprime rien, à part de dire 'je suis un bon informaticien puisque je cause DAO".
Si l'on utilise un framework anglais pour gérer la DAO, les noms sont naturellement en anglais, et je n'y vois aucun inconvénient ; on aura des noms style FactoryMySqlBuilderImplImplDAO. Mais, dès qu'on fait ququchose dessus ou avec, alors on essaiera par ex. AccesEnregistrementsDesVisiteursWeb, par exemple, et je serais même ok pour AccesEnregistrementsDesVisiteursWebDAO, signifiant ainsi qu'on applique ici le modèle DAO, s'il est repris dans le projet.
Bonjour,
Il est très intéressant de lire ce débat. On a eu sensiblement le même débat en interne entre consultants de Xebia.
@Piwai, oui c'est vrai LA difficulté du franglais est de trouver cette fameuse barrière anglais/francais. Pour cela je m'aide du DDD et de l'"ubiquitous language" c'est à dire que j'essaye de construire un langage des termes métiers, que l'on apprend en discutant régulièrement avec le métier et l'équipe. Si le métier parle français je code en français, si le métier parle anglais je code en anglais (avec un traducteur thèmatique), si le métier par le vulcin je code en vulcin
...
Concernant ta remarque sur la non-traduction de "isSatisfiedBy" c'est normal c'est un pattern. Je laisse la paternité du pattern Specification à Eric Evans & Martin Fowler. Si on "google-ise" "isSatisfiedBy" le première lien est la page wikipédia du pattern Specification.
@Edouard Lemaistre voila un exemple très pragmatique de l'utilisation du franglais. Bravo.
@Vincent, tout le monde à Xebia n'était pas d'accord avec le fond de mon article, ce sont leurs convictions et j'ai mes convictions. L'idée est de faire avancer le schilmblic, en présentant des arguments objectifs pour ou contre => un débat constructif et enrichissant
.
@pfff... merci pour ta remarque, ça illuste encore mieux mes propos sur les désaccords que peuvent amener les traductions français/anglais. Je ne suis pas suffisamment bon en anglais pour connaître tous les sens d'un mot anglais d'un contexte fonctionnel donné. Quand je choisis un nom de classe je m'efforce de laisser aucune ambiguïté au sens que je veux donner à cette classe (responsabilité de la classe). En anglais cela est plus difficile pour moi (En toute humilité et je pense que c'est le cas de plusieurs développeurs français).
@Christophe, je suis d'accord avec toi sur les problèmes d'encoding. Je suis en train d'essuyer ces mêmes problèmes en ce moment. Petite apparté sur l'encoding pour moi c'est tout en UTF-8 ! code source, flux, outil, base de données, ... Idéalement, j'évite de mettre des accents dans le code source et la documentation texte (ChangeLog, ReadMe). Ces problèmatiques méritent des articles tellement elles peuvent être génantes et pas si bien maitrisées, même si on baigne dedans depuis tout petit
.
D'accord avec @Hervé A. sur l'utilisation des frameworks anglais et les DAO.
Pour conclure j'ai bien aimé la conclusion de Prisca Polyte (Xebia) lorsque l'on a eu cette discussion en interne à Xebia. Elle rejoint en plusieurs points vos commentaires : je cite "Tout anglais, tout français, peu importe ce qui compte c'est que tous les intervenants se comprennent et puissent échanger sans ambiguïtés. Au sein de l'équipe, le langage se doit être unique, peu importe sa forme. Selon les contextes (corporation, niveau d'expertise), le vocabulaire, les codes, les usages sont naturels comme c'est le cas entre informaticien, "gamers", "geeks", amateurs de BD, "médecins", "flics", etc..... Les équipes projets n'y échappent pas.
[...]. C'est les fonctionnels qui décident. Et pour ce faire, il n'y a pas mieux que le DDD. Dès lors, la création d'un dictionnaire est naturelle et logique. Car au début, les développeurs ne comprennent pas le charabia des fonctionnels (car trop technique , trop axé sur le métier)."
NB : réponse écrite depuis mon écran 20 pouces, pas de problème checkstyle
.