Commentaires

Envoyé par cduigou

[...]
Pourquoi cette manie de choisir des noms de variables et de procédures en anglais[...]

Envoyé par cduigou

[...]Cette anglicisation compulsive n'apporte rien à la compréhension d'un code[...]

Envoyé par cduigou

[...]
* l'anglais dans des noms de procédures ou de variables dans un post pour un portail francophone comme developpez.com : POURQUOI ? POURQUOI ? POURQUOI ? à part un petit snobisme de développeur peut-être ? C'est vrai que ça fait plus clâââsse.. isn't it ?

Envoyé par cduigou

[...]un peu moins de mépris pour tes semblables[...]

Je me demande où est le mépris, depuis le premier de tes postsmessages.

Bref...

Envoyé par Pierre Louis Chevalier

C'est un point de vue intéressant, après moi tous mes stagiaires ont étudié l'anglais...
Quand on est dans un grand groupe international, ou dans un pays multilingues (Suisse, Belgique, etc) utiliser le Français n'est pas du tout une solution.
Donc encore une fois, chacun fait comme il veux, suivant les besoins.

Tu dirais ça dans l'association de pétanque du village de Montcuc je dirais que tu as pas tord, tu dis la même chose dans les bureaux de Cocal Coca Genève la tu passes pour un Péquenaud.

---------------------------------------------------------------------------------------------------------------------------
Allez, un dernier petit coup pour la route parce que ce que je dis n'a pas l'air facile à digérer :
* l'anglais pour un dév Coca machin à Genève : OUI, OUI, OUI, c'est ce que je fais... comme tout le monde dans notre milieu.

* l'anglais dans des noms de procédures ou de variables dans un post pour un portail francophone comme developpez.com : POURQUOI ? POURQUOI ? POURQUOI ? à part un petit snobisme de développeur peut-être ? C'est vrai que ça fait plus clâââsse.. isn't it ?

Maintenant, qui te dit qu'il n'y a pas des anciens de chez Coca truc chez les boulistes ?

Et puis stp, un peu moins de mépris pour tes semblables : un jour ce sera toi le bouliste de Montcuc...

Envoyé par cduigou

A l'inverse, mon cher Pierre, quand le code VBA doit être rendu compréhensible par un public de stagiaires ou de lecteurs francophones, en principe non spécialistes de VBA, je persiste à dire que nommer ses variables, fonctions, procédures, etc.. en anglais ne fait qu'ajouter à la difficulté.

C'est un point de vue intéressant, après moi tous mes stagiaires ont étudié l'anglais...
Quand on est dans un grand groupe international, ou dans un pays multilingues (Suisse, Belgique, etc) utiliser le Français n'est pas du tout une solution.
Donc encore une fois, chacun fait comme il veux, suivant les besoins.

Tu dirais ça dans l'association de pétanque du village de Montcuc je dirais que tu as pas tord, tu dis la même chose dans les bureaux de Cocal Coca Genève la tu passes pour un Péquenaud.

Envoyé par cduigou

[...]Je crois que tu ne veux pas comprendre

Je comprends très bien, mais je n'adhère pas. Ce n'est pas trop difficile à comprendre, normalement. Les codes que je donnes, ICI comme ailleurs, sont en anglais. Tu as ton avis et tes arguments, j'ai les miens... . Prendre l'autre pour un c**quelqu'un qui ne comprend pas ne fera jamais avancer le schmilblick, je pense. Il suffit d'accepter que l'autre a un point de vue différent, pour CE site comme ailleurs.

Envoyé par cduigou

[...]Mais je persiste à dire que par (longue) expérience[...]

C'est ton ressenti, ce n'est pas le mien, malgré ma (longue) expérience en matière de formation à la programmation

Envoyé par cduigou

[...]Maintenant si tu arrives à me démontrer que le libellé anglais apporte quelque chose de plus au stagiaire par rapport au libellé français, je suis preneur de ton argument.

Comme je l'ai déjà dit, je ne cherche pas à démontrer que l'anglais apporte un plus par rapport au français, puisque je suis convaincu que ça n'apporte pas un plus. C'est juste différent, de mon point de vue, et ce n'est ni mieux ni moins bien. Et comme c'est mon habitude de coder en anglais, les codes que je donnes, ici ou ailleurs, sont en anglais. Ca s'arrête juste à ça. Les gens que je forme et ceux à qui je réponds sur ce site ne se sont jamais plaints de cela, jusqu'ici

Maintenant, je vais passer à autre chose. Bonne soirée

Bonjour Pierre,

Je crois que tu ne veux pas comprendre : mon commentaire s'arrête à TA publication ici sur CE site. Je ne mets pas en cause tes habitudes de développement ou d'enseignement.
Inutile donc de partir sur les grands principes en matière de développement VBA, ce n'est pas lesujet d'autant plus que je suis d'accord avec toi à 95% sur ces principes et que je les applique moi-même.

Mais je persiste à dire que par (longue) expérience j'ai constaté que mes stagiaires francophones, pour se placer dans un contexte bien précis, sont plus à l'aise quand je leur donne un exemple de procédure que je nomme Sub MiseAjourFicheClient plutôt que Sub UpdateCustomer : on n'y peut rien, c'est ainsi.

Maintenant si tu arrives à me démontrer que le libellé anglais apporte quelque chose de plus au stagiaire par rapport au libellé français, je suis preneur de ton argument.

Amicalement

Salut Fabien,

Envoyé par f-leb

[...]La coloration syntaxique devrait pas mal aider, non ?[...]

Oui, bien sûr. Du reste, si ça posait vraiment problème, je me demande comment s'en sortiraient les anglophones avec la plupart des langages de programmation. De plus, le but du jeu n'est pas de savoir si on utilise une fonction VBA ou une fonction perso (je ne vois pas trop d'intérêt à pouvoir différencier cela). Je me demande donc pourquoi faire ou pas cette distinction tracasse Claude.

Pour ce qui est des fonctions spécifiques à une application (WriteContactInTable, par exemple), il me semble que tout le monde peut "deviner" que ce n'est pas une fonction native. Pour ce qui est des fonctions génériques (WriteLinesInTextFile, par exemple), le simple fait de préfixer la fonction du nom du module qui la contient (très bonne pratique, au passage, indispensable d'ailleurs lorsque plusieurs modules ont des fonctions nommées de façon identique) permet de savoir qu'elle est rattachée à ce module (outre le fait que la saisie du code est facilitée par la notation pointée). En travaillant ainsi avec un framework (cadre de travail qui permet de fixer les pratiques mais aussi d'utiliser des fonctions de manière systématique), on gagne énormément de temps et de fiabilité sur ses développements. Donc, je ne vois vraiment pas pourquoi Claude se préoccupe de savoir si on utilise un truc du VBA ou pas. On utilise le truc dont on besoin, et c'est cela qui compte au final.

Envoyé par f-leb

[...]Pierre, dans les blogs il faut préciser vba dans les balises code

J'ai corrigé. Merci m'sieur

Salut Claude,

Non non il n'a pas été mal compris. Il se fait simplement que je ne suis pas d'accord avec tes arguments, qui tiennent la route et se défendent mais auxquels je n'adhère pas...

Chacun ses choix, et chacun sa grille de critères, forcément subjective. Nous ne pourrons jamais élaborer une grille de critères objective et opposable à tous (i.e. reconnue universellement), et "nos" bonnes pratiques ne sont jamais que les nôtres. A nous d'argumenter pour convaincre le lecteur, si tant est que la volonté soit de le convaincre, pour qu'il se forge "ses" bonnes pratiques.

C'est juste un point de vue personnel et je n'ai pas plus raison que toi en la matière. Mais je continuerai à coder en anglais, même sur DVP. Et quoi? parce que nous sommes sur un forum francophone, il faudrait que je change mes habitudes? Que je traduise mes fonctions et modules? Tu parles de la satisfaction du client. J'ai deux sortes de clients: ceux pour qui je programme et qui se foutent du code (ils n'y comprendront de toute façon rien) et ceux que je forme sur Excel ou VBA. Les premiers ne verront jamais le code, et les seconds sont bien plus intéressés par ce que je leur explique que par le fait que je nomme mes fonctions en français, en anglais ou en ouzbèke.

Du reste, je me vois mal, pour un client francophone, renommer ma bibliothèque Tools et les fonctions qu'elle contient en français. Et ensuite? Pour un client néerlandophone, je vais devoir renommer Tools en HulpMiddel ou en GereedSchap et WriteLinesInTextFile en LijnenNaarEenTekstBestandSchrijven? Ca n'est pas réaliste pour moi et, dans un souci de systématisation de mon approche, je garderai l'anglais. Ainsi, lorsque je démarre un nouveau développement, je prends mon classeur modèle qui contient la dernière version de mes modules (Tools, xlTools, DateObject, xlTable, xlRow, Factory, ...) et je suis de suite opérationnel de suite grâce à ce FrameWork, en retrouvant mes habitudes d'utilisation de mes fonctions perso et de codage.

Pour ce qui est des formations, j'informe les participants des sessions VBA que l'anglais est de mise pour coder et ça n'a jamais posé problème.

Quant à faire la différence entre les outils natifs du VBA et les fonctions ou modules personnalisés, l'argument ne tient pas pour moi. Comment font les anglophones alors? Ils ne savent pas faire la différence entre les deux et ça ne les gênent pas le moins du monde. Je n'ai jamais entendu que ça posait problème ^^. Si tu veux faire la différence, ne mets pas de majuscule au début du mot. Tous les mots du VBA commençant par une majuscule, la différence sera aisée à faire


Par contre, là où je suis très dubitatif, c'est dans l'utilisation des accents au niveau du code. Crée un classeur avec du VBA accentué sur un Windows puis ouvre-le sur un Mac et tu vas déchanter. J'en ai fait l'expérience il y a quelques années en acceptant, à tort, de développer du VBA qui allait tourner sur un Mac. "Ma" règle, que je considère comme une bonne pratique, est donc de tout coder et nommer en anglais, quelle que soit la destination de ma production, mais surtout, de ne JAMAIS mettre d'accents dans les noms structurels, que ce soit en VBA ou en Access, par exemple, où je bannis les accents des noms des tables et des champs (je nomme d'ailleurs tout en anglais, toujours dans le souci de systématiser l'approche).

Cela dit, merci pour cet échange d'arguments qui est toujours utile. Bon dimanche sous le soleil (du moins chez moi)

Bonsoir,

Envoyé par cduigou

Comment un néophyte peut-il distinguer au premier coup d'oeil qu'un élément de code VBA comme ValidatedCheck n'est pas un mot-clé de VBA mais une variable fonctionnelle correspondant à "Chèque validé" ?

La coloration syntaxique devrait pas mal aider, non ?

Code vba :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub WriteLinesInTextFile(Filename As String, Lines, Optional Replace As Boolean)
  Dim Channel As Long
  Dim i As Long
  ...

Pierre, dans les blogs il faut préciser vba dans les balises code

Bonsoir Pierre,

Je crois que mon post (Hou le vilain mot anglais !!!) a été mal compris.

Bien sûr que quand j'ai comme client un groupe international, moi aussi je choisi des noms de variables, de procédures en anglais, ainsi que les commentaires bien entendu. Quel est le but d'un tel choix ? faciliter la communication entre les parties pour la prise en main de la maintenance par le client par exemple. Nous sommes bien d'accord sur ce point.

A l'inverse, mon cher Pierre, quand le code VBA doit être rendu compréhensible par un public de stagiaires ou de lecteurs francophones, en principe non spécialistes de VBA, je persiste à dire que nommer ses variables, fonctions, procédures, etc.. en anglais ne fait qu'ajouter à la difficulté. Comment un néophyte peut-il distinguer au premier coup d'oeil qu'un élément de code VBA comme ValidatedCheck n'est pas un mot-clé de VBA mais une variable fonctionnelle correspondant à "Chèque validé" ?

Tu me dis "De plus, VBA est en anglais...." et donc écrivons tout ce qui n'est pas VBA en anglais aussi ! C'est assez curieux comme logique : pour moi la conclusion aurait dû être l'inverse non ?

Tu dis "je préfère utiliser GetParameter dans mon AppTools plutôt qu'une Fonction1 dans Module1"... mais bien entendu. Cela dit, utiliser LitParamètre dans ton module OutilsApp serait très bien aussi.

Quant à "chacun ses choix", je ne suis pas d'accord : le but est la satisfaction du client, pas celle du développeur. C'est à nous de nous adapter et en la matière, comme je viens de l'expliquer plus haut, il n'y a pas une vérité mais plusieurs : anglais quand il faut, français quand c'est préférable. Et je crois que sur developpez.com nous sommes dans un site francophone, d'où ma réaction.

Pour conclure, ce que nous venons d'échanger ici c'est peanuts (Oups !) par rapport à l'intérêt de ton article 😄


Bonne soirée et bon week-end.

Salut Marcel,

VBA.Array force l'indice à 0 pour la première ligne du tableau, indépendamment de la ligne Option Base en début de module (voir cette réponse de ma part dans une discussion sur le sujet).

Perso, à part éventuellement dans un module de classe, et encore, je déconseille de jouer avec Option Base puisqu'un même code, copié d'un module à un autre, pourrait ne pas produire le même résultat si les deux modules n'ont pas le même Option Base.

Envoyé par Pierre Louis Chevalier

[...]

Bonsoir Claude,

Merci pour ton intervention et ton apport.

Envoyé par cduigou

[...]
Pourquoi cette manie de choisir des noms de variables et de procédures en anglais[...]

D'abord, comme le dit Pierre Louis, parce que chacun fait comme il veut... Certains codent en séparant les mots par un _ (Ecrire_Dans_Fichier) alors que d'autres, comme moi, utilisent la CamelNotationnotation chameau (EcrireDansFichier)

Ensuite, comme le dit encore Pierre Louis, lorsque l'on travaille sur des projets internationaux, l'anglais va s'imposer naturellement. Si, comme moi, on travaille dans un pays possédant trois langues nationales, il faut soit en choisir une et se mettre les autres à dos, soit choisir la "moins pire" des solutions et coder en anglais. J'ai travaillé sur un projet pour lequel j'allais rechercher des données dans une DB en néerlandais (Klant et parfois Kt pour client) et d'autres données dans le logiciel de compta développé dans la partie germanophone de la Belgique ou j'allais rechercher des comptes (Konto ou ... Kt) . Je me suis "amusé" comme un petit fou , moi qui ne parle quasiment pas néerlandais et encore moins l'allemand. Je passe sur le fait que dans la DB en néerlandais, par manque de rigueur, certaines clés externes vers le Kt_ID étaient nommées... CustomerID.

De plus, VBA est en anglais, comme le montre d'ailleurs le code proposé en commentaire. On travaille avec des worksheets, des workbooks, des range, des activesheet, des names, des paths, parce que les noms des objets du modèle objet Excel sont en anglais et que les noms des méthodes et propriétés de ces objets sont en anglais. On ne peut pas écrire Fin Sub, si on cherche la valeur ou l'adresse d'une plage, on peut utiliser MaPlage, mais on devra utiliser MaPlage.Value ou MaPlage.Address, et pas MaPlage.Valeur ou MaPlage.Adresse. Les évènements sont également en anglais: Private Sub Workbook_BeforeClose(Cancel As Boolean) et pas Privée SousRoutine Classeur_AvantFermeture(Annuler Comme Booléen) . Du coup, je ne vais pas faire un caca nerveux sur les noms anglais puisque de toute façon le VBA en est truffé et pas que lui d'ailleurs.

Bref, j'ai pris l'habitude de nommer tout en anglais dans VBA, mais de manière explicite. Je préfère d'ailleurs utiliser une fonction GetParameter dans mon AppTools plutôt qu'une Fonction1 dans Module1

Après, comme dit plus haut: chacun ses choix. Perso, je préfère voir quelqu'un coder proprement en anglais en respectant une architecture et les bonnes pratiques, que de le voir coder comme un pied en français


Dans le code donné, la seule chose que l'on peut franciser, c'est Dim MaPlage à la place de Dim Range. TOUT le reste sera en anglais. Du coup, je ne vois pas bien l'intérêt. Perso, j'aurais utilisé Dim MyRange As Range ou Dim rngContacts As Range pour préciser vers quoi pointe la plage.

Code vba :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Sub test()
    Dim Range As Range
    Set Range = ActiveSheet.Range("A1:A3")
    MsgBox Range.Address
End Sub

Je pense que l'important à retenir de mon billet, c'est le fait qu'il faut déterminer une architecture et s'y tenir en privilégiant, selon mon expérience, l'écriture d'un code générique réutilisable. Pour autant que les noms des procédures, fonctions et variables soient explicites, le reste m'importe peu.


Cordialement,

Si je peux me permettre, pour ceux qui travaillent dans un grand groupe international c'est tout à fait normal de faire du code en Anglais et pas en Français après la dessus chacun fait ce qu'il veux.

Cher Pierre,
Quelques remarques sur la forme de votre article plutôt que sur le fond, qui au demeurant est très intéressant.
Pourquoi cette manie de choisir des noms de variables et de procédures en anglais pour un code qui, je pense, est destiné à être lu par des francophones ?
Au contraire, nous avons la chance de ne pas nous exprimer nativement en anglais : profitons-en pour écrire nos choix en français, bonne façon de voir tout de suite dans le code ce qui concerne notre fonctionnel et ce qui concerne VBA.

Sub EcritLignesDansFichierTexte(NomFichier As String, Lignes, Optional Remplace As Boolean) est je pense aussi explicite que Sub WriteLinesInTextFile(Filename As String, Lines, Optional Replace As Boolean) non ?

Pareil pour log ou pour channel... Quel intérêt par rapport à leurs équivalent français ?

Ou encore un module Tools de préférence à Outils ?

Cette anglicisation compulsive n'apporte rien à la compréhension d'un code.
Le code VBA suivant est une absurdité rédactionnelle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Sub test()
    Dim Range As Range
    Set Range = ActiveSheet.Range("A1:A3")
    MsgBox Range.Address
End Sub

et pourtant il fonctionne !

Bien cordialement

Claude DUIGOU

Salut Marcel,


Réponse tardive, mais oui, tu as bien compris. Il suffit de regarder le code que je fournis dans le billet pour se convaincre que c'est BEAUCOUP plus simple!

Salut.

Merci pour ton appréciation

Perso, je mettrais le tableau de config dans le fichier qui contient la solution Power Query. En gros, j'ai la configuration suivantes:

• Fichiers de données (Excel et autres sources);
• Fichier tableau de bord et analyse qui contient la solution Power Query.

C'est dans ce second fichier que j'ai un tableau structuré avec les paramètres. Rien n'empêche cependant de placer ces paramètres dans un autre fichier, mais il faut évidemment que son emplacement soit fixe sinon, on revient au point de départ. Donc je pense que c'est un peu se compliquer la vie de sortir les paramètres Excel utilisés par Power Query du fichier qui contient la solution Power Query. Il faudrait que tu détailles ton besoin dans une discussion du forum pour obtenir d'autres regards plus centrés sur TA configuration

Bonjour Pierre,

Merci beaucoup pour cette démonstration. Personnellement, je l'ai trouvé très intéressante car il est vrai que c'est fatiguant de changer les liaisons manuellement à chaque fois et souvent on se trompe

je voudrais juste savoir si c'est obligatoire que le paramétrage du chemin soit fait dans le même fichier excel qu'on va travailler ou on peut également paramétrer dans un autre fichier par exemple ou on a réuni toute la partie config.

Merci d'avance !

Bonsoir Pierre,

Tout à fait. Dans mes notes, j'avais mentionné de parler de cette bizarrerie, dont je parle dans cette discussion, et puis c'est passé à la trappe.

Merci d'avoir relevé ce problème Heureusement qu'avec Excel, on manipule somme toute assez rarement des dates des deux premiers mois de l'année 1900, mais c'est ahurissant tout de même, une erreur de ce genre. Errare humanum est

Bonjour Pierre

Je viens de tomber par hasard sur ton article.
Ta dernière formule est juste... à un détail près. Le dernier jour de février de l'année 1900.

Comme tu dois le savoir, Excel traîne depuis sa création une erreur sur le dernier jour de février de 1900. Excel indique qu'après le 28/02/1900, c'est le 29/02/1900. Or cette date n'existe pas.

C'est bien la preuve que les concepteurs d'Excel ne savaient par que l'année bissextile n'était pas systématiquement tous les quatre ans

Au passage, cela veut aussi dire que le numéro de série d'une date d'Excel n'est pas le nombre de jours écoulés depuis le 01/01/1900 puis qu'il y a un jour un trop. Et aussi qu'un calcul de différences de dates renvoie une erreur si la première date est avant le 28/02/1900 et que la deuxième se situe après

Mais, on s'en moque puisque c'est un calcul que l'on ne fait jamais.

C'était juste pour l'anecdote et cela ne prête pas à conséquence bien grave.

Pierre Dumas

Bonjour,

Si j'ai bien compris.
La gestion de Combobox en cascades va très avantageusement être simplifiée.

Merci.