Ca a plusieurs avantages :
- avoir la précision du français (ça me gonflerai de chercher la traduction d’un mot)
- distinguer le code utilisateur et le code système : quand je lis « getTime », je pense à une fonction système. Quand je lis « lireDate » ou « lireDateHeure » ou « lireHeure », je pense toujours à une fonction créée par le développeur de l’appli.
- éviter de chercher un nom en anglais quand celui-ci est trop proche d’un nom système : c’est un énorme avantage d’avoir une seconde langue. Quand je vois des « $this » en PHP, je trouve ça illogique de créer une variable portant le même nom qu’un mot-clé.

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 .

@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.

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

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.

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…..

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.

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?

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

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…

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.

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.

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.