IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Pierre Fauconnier

[Actualité] VBA: Créer et gérer le fichier de log d'une application Office

Note : 2 votes pour une moyenne de 3,50.
par , 16/09/2021 à 21h53 (6851 Affichages)
Salut.

Il est courant de devoir consigner certains évènements survenant lors de l'utilisation d'une application, VBA ou autre, et ces données sont souvent écrites dans un fichier de log. Que ce soit à l'ouverture ou la fermeture du fichier, lorsque certaines erreurs surviennent, ou lors de manipulations délicates des données, conserver une trace de "ce qui s'est passé" est un bon moyen de pouvoir suivre l'utilisation d'une appli et de la déboguer rapidement lorsqu'un problème survient.

Le traçage d'un fichier Excel à l'aide d'un mouchard (??), l'historique d'un fichier, la liste des utilisateurs du fichiers et ce qu'on y fait (sélection d'une feuille que l'on pense inutilisée, par exemple, ...) sont des activités qui peuvent renseigner sur l'utilisation d'un fichier et donner des pistes d'améliorations intéressantes.

Cadre de travail

Dans ce billet, je généralisais l'écriture dans un fichier texte grâce à une procédure générique, de manière à ajouter de l'abstraction et à ne plus devoir se préoccuper de la technique d'écriture dans un fichier. En effet, devoir écrire dans un fichier texte requiert de savoir ouvrir un fichier (un "canal"), d'utiliser des instructions pour dire que l'on remplace le contenu ou que l'on en ajoute, sans oublier bien entendu de fermer le fichier après écriture. Tout cela peut être inclus dans une procédure au nom évocateur de WriteLinesInTextFile qui est appelée comme une instruction native du VBA et qui pourrait être stockée dans un module "Tools" comme je l'explique dans ce billet, puisque générique à VBA et donc, non spécifique à une techno particulière.

Code vba : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Sub WriteLinesInTextFile(Filename As String, Lines, Optional Replace As Boolean)
  Dim Channel As Long
  Dim i As Long
 
  Channel = FreeFile
  If Replace Then
    Open Filename For Output As Channel
  Else
    Open Filename For Append As Channel
  End If
  For i = LBound(Lines) To UBound(Lines)
    Print #Channel, Lines(i)
  Next i
  Close Channel
End Sub
Code : Sélectionner tout - Visualiser dans une fenêtre à part
Tools.WriteLinesInTextFile "c:\data\temp\Monfichier.txt", Array("Pierre", "Martine", "Manon"), True
.

Cahier des charges

Poursuivons dans la systématisation de notre approche de programmation en formalisant l'écriture de logs lors de l'utilisation de notre application.

En général, un fichier de log est créé pour être aisément lisible. Ce sera donc souvent un simple fichier texte dons la ligne est structurée, plus rarement un CSV, même si ce format peut être pratique pour une exploitation rapide en Excel. Chaque développeur fera "à sa sauce" en la matière. Ce qui importe, c'est que le fichier soit exploitable et qu'il permette de savoir rapidement ce qui s'est passé dans l'appli. On pourrait ainsi avoir un fichier de log qui ne reprend que les erreurs survenues durant l'exécution, un log à l'ouverture et la fermeture, un log à l'enregistrement du fichier, etc...

Pour l'exemple, notre cahier des charges mentionne que l'on souhaite:
  • un log pour l'ouverture du fichier;
  • un log pour la fermeture du fichier;
  • un log pour la sauvegarde du fichier;
  • un log pour certaines erreurs que l'on veut pouvoir tracer;
  • le log reprendra également le moment du log, ainsi que l'utilisateur actif.



Création de la ligne de log

Regardons d'abord où et comment coder l'écriture du log.

Dans la mesure où le log dépend de l'application, il semblera normal que la fonction d'écriture du log se trouve dans le module de l'application. Fidèle à mes bonnes pratiques de codage et comme je le mentionne dans un billet de blog cité plus haut, mes développements contiennent un module appTools qui reprend des fonctions spécifiques de mon application (récupération de paramètres, version et date de l'application, nom de l'application à utiliser dans les msgbox, etc). Tout naturellement, j'insérerai dans ce module la fonction WriteLog qui reprendra les données prévues dans le cahier des charges.

Code vba : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
Sub WriteLog(Message As String)
  Dim DateLog As String
  Dim FileName As String
 
  DateLog = Format(Now, "yyyy-mm-ddThh:nn:ss")
  FileName = ThisWorkbook.Path & "\" & Replace(ThisWorkbook.Name, ".", "_") & ".log"
  Message = DateLog & " | " & Environ("username") & " | " & Message
  Tools.WriteLinesInTextFile FileName, Array(Message), False
End Sub

Normalement, cette fonction se passe de commentaires. Elle formate la ligne du log en reprenant le moment du log normalisé, le nom de l'utilisateur puis le message reçu en argument. Elle crée aussi le nom du fichier de log qui reprend le nom du fichier et lui ajoute l'extension .log. Lorsque la ligne de log est créée, la fonction appelle la fonction générique Tools.WriteLinesInTexteFile vue en début de billet. On remarque donc ici que le programmeur n'a pas besoin de savoir comment on écrit dans un fichier texte avec Open, Append, Close & Cie, il utilise la fonction de appTools qui elle-même utilise la fonction du Tools. On lui a donc bien permis de faire abstraction de toute la mécanique d'écriture.


Création des logs lors d'évènements ou à des moments clé de l'exécution

Il suffit maintenant au programmeur d'appeler la fonction appTools.WriteLog lors de la survenance d'évènements ou erreurs, ou à des passages clé du code. Pour coller au cahier des charges, voici les évènements de classeur qui doivent déclencher l'écriture d'un log. On remarque ici que l'on se contente de passer le message à WriteLog puisque c'est cette fonction qui va composer la ligne du log.

Code vba : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
Private Sub Workbook_BeforeClose(Cancel As Boolean)
  appTools.WriteLog "Fermeture du fichier"
End Sub
 
Private Sub Workbook_BeforeSave(ByVal SaveAsUI As Boolean, Cancel As Boolean)
  appTools.WriteLog "Enregistrement du fichier"
End Sub
 
Private Sub Workbook_Open()
  appTools.WriteLog "Ouverture du fichier"
End Sub

Voici également une erreur qui doit déclencher l'écriture du log (c'est, évidemment, pour l'exemple). On remarquera que comme le message est un peu particulier puisqu'il reprend le numéro et la description de l'erreur, on passe par un appTools.LogError qui utilise l'erreur active pour constituer le message qui sera envoyé à appTools.WriteLog qui lui même formatera la ligne pour l'envoyer à Tools.WriteLinesInTextFile.

Code vba : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
Sub Test()
  On Error GoTo Catch
 
  Debug.Print 5 / 0
 
Catch:
  If Err <> 0 Then appTools.LogError
End Sub

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
Sub LogError()
  Dim Message As String
  
  Message = Err.Number & " - " & Err.Source & " - " & Err.Description
  WriteLog Message
End Sub

Voici, pour l'exemple, le contenu du fichier Log après quelques utilisations (ouverture, erreur division par zéro, enregistrement, fermeture, puis à nouveau ouverture, et fermeture après travail et demande d'enregistrement lors de la fermeture).

Code text : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
2021-09-16T20:22:41 | PierreFauconnier | Ouverture du fichier
2021-09-16T20:33:44 | PierreFauconnier | 11 - VBAProject - Division par zéro
2021-09-16T20:33:46 | PierreFauconnier | Enregistrement du fichier
2021-09-16T20:33:53 | PierreFauconnier | Fermeture du fichier
2021-09-16T20:35:29 | PierreFauconnier | Ouverture du fichier
2021-09-16T20:38:15 | PierreFauconnier | Fermeture du fichier
2021-09-16T20:38:18 | PierreFauconnier | Enregistrement du fichier


Conclusions

On remarque, à nouveau, qu'une approche systématique de nos développements nous permet de créer du code récupérable d'un projet à l'autre. La constitution de bibliothèques contenant VOS fonctions et procédures va vous permettre un gain de temps et une fiabilité accrue sur vos développements.

N'hésitez pas à commenter ce billet. C'est toujours intéressant d'avoir un retour sur mes astuces et bonnes pratiques

Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Viadeo Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Twitter Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Google Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Facebook Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Digg Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Delicious Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog MySpace Envoyer le billet « VBA: Créer et gérer le fichier de log d'une application Office » dans le blog Yahoo

Commentaires

  1. Avatar de cduigou
    • |
    • permalink
    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
    Mis à jour 17/09/2021 à 20h16 par Pierre Fauconnier (Balises de code svp: sélection du code puis bouton # de la barre d'édition du message. Merci)
  2. Avatar de Pierre Louis Chevalier
    • |
    • permalink
    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.
  3. Avatar de Pierre Fauconnier
    • |
    • permalink
    Bonsoir Claude,

    Merci pour ton intervention et ton apport.

    Citation 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,
    Mis à jour 19/09/2021 à 11h03 par Pierre Fauconnier
  4. Avatar de Pierre Fauconnier
    • |
    • permalink
    Citation Envoyé par Pierre Louis Chevalier
    [...]
  5. Avatar de cduigou
    • |
    • permalink
    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.
  6. Avatar de f-leb
    • |
    • permalink
    Bonsoir,

    Citation 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
  7. Avatar de Pierre Fauconnier
    • |
    • permalink
    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)
    Mis à jour 19/09/2021 à 11h46 par Pierre Fauconnier
  8. Avatar de Pierre Fauconnier
    • |
    • permalink
    Salut Fabien,

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


    Citation Envoyé par f-leb
    [...]Pierre, dans les blogs il faut préciser vba dans les balises code
    J'ai corrigé. Merci m'sieur
    Mis à jour 19/09/2021 à 21h24 par Pierre Fauconnier
  9. Avatar de cduigou
    • |
    • permalink
    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
  10. Avatar de Pierre Fauconnier
    • |
    • permalink
    Citation 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.



    Citation 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



    Citation 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
    Mis à jour 24/09/2021 à 11h16 par Pierre Fauconnier
  11. Avatar de Pierre Louis Chevalier
    • |
    • permalink
    Citation 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.
  12. Avatar de cduigou
    • |
    • permalink
    Citation 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...
  13. Avatar de Pierre Fauconnier
    • |
    • permalink
    Citation Envoyé par cduigou
    [...]
    Pourquoi cette manie de choisir des noms de variables et de procédures en anglais[...]
    Citation Envoyé par cduigou
    [...]Cette anglicisation compulsive n'apporte rien à la compréhension d'un code[...]
    Citation 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 ?

    Citation 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...
    Mis à jour 22/09/2021 à 12h06 par Pierre Fauconnier
  14. Avatar de Pierre Louis Chevalier
    • |
    • permalink
    Citation Envoyé par cduigou
    ---------------------------------------------------------------------------------------------------------------------------
    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...
    C'est une référence humoristique, après si tu fais parti des gens qui ont pas l’humour j'y peux rien



    Tu as le droit de faire ton code en Français, mais je ne voie pas pourquoi ça deviendrait obligatoire pour tous le monde
    Pendant que tu y es achète WinDev mais fait tes variables en anglais ou en polonais pour que ça se mélange pas avec le code du wlangage en français, et voila tu es cohérent avec toi même, mais rien ne t'oblige à vouloir imposer ta vision des choses à tous le monde coute que coute
  15. Avatar de cduigou
    • |
    • permalink
    Citation Envoyé par Pierre Louis Chevalier
    [...]Tu as le droit de faire ton code en Français, mais je ne voie pas pourquoi ça deviendrait obligatoire pour tous le monde
    Pendant que tu y es achète WinDev mais fait tes variables en anglais ou en polonais pour que ça se mélange pas avec le code du wlangage en français, et voila tu es cohérent avec toi même, mais rien ne t'oblige à vouloir imposer ta vision des choses à tous le monde coute que coute
    Bon allez, je crois que c'est cuit... définitivement.

    Au fait, dans le petit village qui te tient à coeur, il y a toujours ce magasin d'articles de cuisine ? Celui où on peut acheter les célèbres poëles de Montcuc ? 🤣🤣🤣
    Mis à jour 24/09/2021 à 12h51 par Pierre Fauconnier (Merci de baliser correctement vos messages!)
  16. Avatar de Pierre Fauconnier
    • |
    • permalink
    Citation Envoyé par Pierre Louis Chevalier
    [...]

    Tu as le droit de faire ton code en Français, mais je ne voie pas pourquoi ça deviendrait obligatoire pour tous le monde
    Pendant que tu y es achète WinDev mais fait tes variables en anglais ou en polonais pour que ça se mélange pas avec le code du wlangage en français, et voila tu es cohérent avec toi même[...]



    En fait, t'as rien compris. Ce sont les anglais qui codent avec WinDev. Comme ça, ils nomment leurs fonctions et leurs variables en anglais, leur langue natale, puisque c'est comme ça qu'il faut faire qu'il a dit le môssieur, et alors ils voient bien la différence entre le langage FR et les variables EN...
    Mis à jour 27/09/2021 à 10h37 par Pierre Fauconnier
  17. Avatar de LiliV
    • |
    • permalink
    Bonjour les amis,

    Mon père aurait dit : "Ne te laisse pas énerver par ça ! "
    Je pense qu'il était très sage.
  18. Avatar de Pierre Fauconnier
    • |
    • permalink
    Citation Envoyé par LiliV
    ...
    C'est vrai que pour le coup, j'ai nourri le troll de service...