Mieux vaut toujours garder l'anglais comme langue pour nommer les variables, les fonctions...
Oui sauf qu'en France les spec sont souvent écrites en Français, et les gens parlent entre eux en Français.
Traduire en anglais introduit une ambiguïté, et en plus en France on est pas très fort en anglais, et je t'assure que ça pose problème, entre ceux qui comprenne rien, et ceux qui introduise des traduction toute pourrie.
- Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.
Tout à fait d'accord, et là je trouve que ça se justifie pleinement d'investir dans une conception en anglais. AMA il faut a tout pris éviter de concevoir en français pour traduire ensuite, il faut tout faire en anglais, dès la conception fonctionnelle.
- En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
Les langages qui ne gère pas les accents, ça suxxx.
Bon, dans la réalité je n'utilise pas les accents dans le code, mais avec un langage moderne (Python, Java) ça ne pose aucun problème. D'ailleurs c'est un indice pour la gestion de l'internationalisation. Par exemple Ruby suxxx, à ce niveau là.
- Ca fait réviser l'anglais.
C'est bien ce que je dis, beaucoup de gens ne maîtrisent pas l'anglais, et sur un projet, ça peut faire mal.
Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.
Je suis d'accord, c'est moche, mais parfois c'est un moindre mal.
Dans le cas de spec en français, je garde le vocabulaire métier en français, et le reste en anglais et je les compose à l'anglaise.
Par exemple pour une méthode qui crée une facture, je l'appelle
createFacture, car tout le monde parle de "facture" quand on discute, et pas de "invoice"
Et de toute façon, il y a un certain nombre de dev qui ne connaissent pas le mot "invoice" et mettront "facture" dans leur code
[^] # Re: Parler anglais
Posté par パパフラクス . En réponse au journal Bonnes pratique pour le développement. Évalué à 3.
Oui sauf qu'en France les spec sont souvent écrites en Français, et les gens parlent entre eux en Français.
Traduire en anglais introduit une ambiguïté, et en plus en France on est pas très fort en anglais, et je t'assure que ça pose problème, entre ceux qui comprenne rien, et ceux qui introduise des traduction toute pourrie.
- Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.
Tout à fait d'accord, et là je trouve que ça se justifie pleinement d'investir dans une conception en anglais. AMA il faut a tout pris éviter de concevoir en français pour traduire ensuite, il faut tout faire en anglais, dès la conception fonctionnelle.
- En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
Les langages qui ne gère pas les accents, ça suxxx.
Bon, dans la réalité je n'utilise pas les accents dans le code, mais avec un langage moderne (Python, Java) ça ne pose aucun problème. D'ailleurs c'est un indice pour la gestion de l'internationalisation. Par exemple Ruby suxxx, à ce niveau là.
- Ca fait réviser l'anglais.
C'est bien ce que je dis, beaucoup de gens ne maîtrisent pas l'anglais, et sur un projet, ça peut faire mal.
Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.
Je suis d'accord, c'est moche, mais parfois c'est un moindre mal.
Dans le cas de spec en français, je garde le vocabulaire métier en français, et le reste en anglais et je les compose à l'anglaise.
Par exemple pour une méthode qui crée une facture, je l'appelle
createFacture, car tout le monde parle de "facture" quand on discute, et pas de "invoice"
Et de toute façon, il y a un certain nombre de dev qui ne connaissent pas le mot "invoice" et mettront "facture" dans leur code