Bonjour Vobul,
Tout d'abord un grand merci à toi pour ce retour, c'est vraiment intéressant de pouvoir échanger ici.
Vobul a écrit
Remarque : dans le code, mon avis perso c'est de toujours coder en anglais. Même si ton public est français, le code doit être en anglais. À chaque fois que je vois du code écrit en français je me dis que c'est dommage de couper la participation des non francophones (ça marche avec les autres langues que l'anglais hein). Tous les codeurs du monde savent lire l'anglais. Si ton code est en anglais, il pourra être repris et amélioré par une communauté bien plus grande que s'il est dans une langue autre. Certes beaucoup de gens parlent et lisent le français, mais on est plus au 17ème siècle, désormais c'est l'anglais qui domine.
Exemple concret : la fonction
getParametres. En français ça devrait être Paramètres, et non pas Parametres. Et puis "get", c'est de l'anglais non ? Donc tu te retrouves avec un truc dans une langue hybride et ça craint du boudin. Alors que getParameters(), ça tout le monde comprend tout de suite. Francophone ou pas. De plus, l'anglais a pas mal d'avantage côté code, les mots de trois lettres (get/set/die/put), pas d'accents, moins de lettres à taper pour décrire la même chose qu'en français. Bien sûr cela ne doit pas empêcher que le logiciel parle français. Mais au lieu de hardcoder les strings en français, utilise un outil i18n pour qu'à l'avenir ajouter une langue soit aussi simple qu'ajouter un fichier de traductions.
https://docs.python.org/3/library/i18n.html. Et puis python est tellement naturel comme language, c'est beaucoup plus lisible quand c'est en anglais… Là lire le code c'est passer sans cesse du français à l'anglais tous les deux mots c'est éreintant.
J'espère que j'ai made my point :p
À vrai dire, le choix du français est plutôt volontaire. L'utilitaire répondant à une problématique purement française (obligations déclaratives des exécutants de travaux en France), je sais que cet utilitaire n'aura pas d'utilité en-dehors des frontières du pays. Je trouvais donc le choix du français plutôt justifié ici.
Après, j'entends l'argument sur l'utilisation du « franglais » dans le code, et je reconnais que le résultat n'est effectivement pas satisfaisant : je procéderai certainement différemment à l'avenir.
En revanche, je pense maintenir, pour ce logiciel, l'utilisation du français pour les commentaires et l'interface du logiciel, pour la raison déjà évoquée que ce projet n'a pas vocation à être utilisé à l'international. Pour les commentaires, je pense effectivement que je perdrais en précision en utilisant l'anglais (en raison de mon faible niveau), alors que je suis persuadé que le public amené à le lire sera francophone à au moins 99 %.
Effectivement, un commentaire serait ici le bienvenu. Je l'avais ajouté car dans mes tests, en l'absence de cette instruction, « calendar.day_name » et « calendar.month_name » renvoyaient par défaut les noms des jours et des mois en anglais.
Après, si quelqu'un a son système dans une langue étrangère, cela aboutira à un mélange de langues. Compte tenu de ce que j'évoquais plus haut sur l'utilisation du programme en français, il serait peut plus cohérent d'utiliser quelque chose du type « locale.setlocale(locale.LC_ALL, 'fr_FR') » pour prendre le parti de forcer le français et d'avoir ainsi une interface cohérente, mais ça demanderait un peu plus de travail pour être propre (gérer l'absence de la langue française sur le système, modifier l'argument 'fr_FR' selon le système utilisé, etc.).
D'ailleurs, je constate que cette ligne apparaît également dans le fichier main.py (l'une des deux instructions est donc superflue).
Vobul a écritRemarque 3 : la première ligne des fichiers devrait être #!/usr/bin/env python. Il est peut-être nécesssaire d'ajouter un check de la version de python dans le programme afin qu'il quitte si c'est python 2. Mais là t'as mis /usr/bin/python3.5. Or sur mon ordi (avec Archlinux) j'ai 3.6.2, donc si je fais ./main, ça marche pas.
Effectivement, il n'y pas lieu de bloquer la version sur la 3.5. En revanche, l'en-tête « #!/usr/bin/python3 » ne ferait-il pas l'affaire ?
Vobul a écritAlors ensuite comme je suis pas trop neuneu je fais "python main.py" et là j'ai une erreur : ModuleNotFoundError: No module named 'PyPDF2'.
Ah tiens, t'aurais pas oublié une étape dans le readme genre pour installer les dépendences ? Regarde ce que c'est que requirements.txt 😉
Alors comme je suis pas trop neuneu je fais "sudo pip install pypdf2".
Effectivement, PyPDF2 est nécessaire. Je vais jeter un coup d'oeil sur le fonctionnement de requirements.txt 😉
Vobul a écritMaintenant l'erreur c'est qu'il trouve pas XDG_CONFIG_HOME. Eh oui, sur mon système la variable XDG_CONFIG_HOME n'existe pas ! Donc il faut que t'ajoutes du code soit pour montrer une belle erreur explicative, soit tu mets ça dans le fichier de conf, soit tu cherches d'autres répertoires. Mais là c'est moche :p
Je pensais naïvement que XDG_CONFIG_HOME était universel sur GNU/Linux. L'idéal serait de chercher le bon répertoire. Il n'y a pas, par défaut, de variable d'environnement renvoyant au « .config » de l'utilisateur courant sous Archlinux ?
Vobul a écritAlors comme je suis pas trop neuneu je fais "export XDG_CONFIG_HOME=/tmp/yep" et je relance. Ah j'ai une fenêtre, on avance 🙂 Je clique sur paramètres et je rentre ma config. Et oh surprise je retrouve mon mot de passe de ma messagerie électronique dans un fichier texte dans la nature. Pas cool. Le mot de passe smtp devrait être chiffré. Alors oui c'est pas forcément facile à faire, mais ça vaut le coup. Personne ne pourra prendre ce programme au sérieux tant que le mot de passe est stocké en clair.
https://www.google.fr/search?q=python+store+encrypted+data Et conseil important : n'essaie pas d'inventer ta crypto, utilise une librairie, fais pas le foufou.
La gestion du mot de passe est effectivement, à l'heure actuelle, le gros point noir de cet utilitaire.
Mes réflexions sur le sujet :
- comme le mot de passe doit être envoyé au serveur, j'ai besoin d'un algorithme permettant de déchiffrer le mot de passe avant l'envoi. Donc de ce que je comprends, je ne peux pas utiliser le module hashlib.
- j'ai vu le module base64 qui permet me semble-t-il d'encoder et de décoder à la volée. Mais stocker un mot de passe encodé en base64 est-il réellement utile niveau sécurité ? Ce sera toujours mieux que stocké en clair de toute façon.
Aurais-tu des recommandations sur le sujet ?
Vobul a écritEnsuite je vois que par défaut tu mets /home/user/Téléchargements comme dossier. Mais tu devrais te baser sur XDG_DOWNLOAD_DIR vu que t'aimes bien XDG 😉
Je ne connaissais pas. Effectivement, je pourrai l'utiliser (avec une solution de secours s'il n'est pas défini).
Vobul a écritBon allez pour finir deux trois trucs en vrac :
Vobul a écrit- fais des paquets et mets sur pypi.org comme ça on peut "pip install declatravaux" et ça gère les dépendances, ça vérifie que c'est python 3 toussah.
Ce serait effectivement plus propre.
Je pensais également utiliser cx_freeze pour créer des exécutables, afin de rendre le logiciel utilisable sans avoir à se soucier de l'installation de python (notamment) sur le système. Ça a l'air de fonctionner sous Windows, je n'ai pas encore testé cx_freeze sous Ubuntu (j'imagine qu'il crée un fichier en .sh).
Vobul a écrit- dans getCheminFichierConfig() t'as oublié les macs, non ?
En effet, Mac OS n'est pas du tout géré dans le code, tout simplement car je ne dispose pas du système pour tester. Mais pourquoi pas à terme, si j'ai déjà réglé tous les autres problèmes, ou s'il y a une demande particulière en ce sens !
Vobul a écrit- essaie de ne pas te répéter dans ton code. getParametres et setParametres sont identiques à 80%. Sors le code de là, mets-le dans une autre fonction (genre init()) au lieu de le copier coller ! (
principe DRY)
Effectivement, c'est bien noté.
Vobul a écrit- change le nom du fichier de licence en LICENCE
C'est une convention ? Je crois d'ailleurs que Gitlab ne reconnaît que le fichier LICENSE (en anglais).
Il y a effectivement des tabulations inutiles sur les lignes vides. D'ailleurs, je crois avoir compris qu'il faut éviter les tabulations, et préférer les espaces (4 par niveau d'indentation) ?
Vobul a écrit- pourquoi certains fichiers sont chmod +x et pas d'autres ?
C'est totalement involontaire. Y a-t-il une bonne pratique en la matière ? Tout mettre en non exécutable ?
Vobul a écritBon et pour finir sur une bonne note je dirai que pour un premier programme c'est pas mal du tout, on a vu bien pire, et je ne vise personne sur ce forum :p C'est plutôt organisé et propre. Mais t'as encore un peu de boulot 😉
Merci 🙂
Il reste beaucoup de boulot, mais ce n'est pas comme si c'était une surprise.
En tout cas, je te remercie encore pour le temps que tu m'as consacré, sur un programme qui ne t'intéresse pas le moins du monde j'imagine 😉. C'est vraiment très appréciable !
