15-09-2019, 12:17:59
kimented :
Ya plusieurs choses qui me dérange dans ton soft.
Le but n'est bien évidement de critiquer mais de transmettre mon expérience et améliorer la maintenance/évolution du soft.
1. Les 4 variantes sont à 80 % du copié/collé.
C'est pas pratique pour faire évoluer ton soft. A chaque modifs, faut penser à le faire 4 fois.
Le mieux dans ce cas (en python) est de faire de l'héritage.
Une classe parente qui fait les opérations identiques et des classes enfants qui font avoir les opérations spécifiques.
2. Les imports avec des "*". Deux soucis liés à ça :
- ça va charger en mémoire des choses inutiles.
- ça peut occasionner des conflits de nom.
Ex : from dep1 import * et from dep2 import *
Toutes les 2 ont la fonction "display"
python plante quand on fait un "display()" car il sait pas laquel utilisé.
Avec des imports strictes, tu t'en rends compte dès le début et surtout tu évites des comportements bizarres quand tu fais des upgrades de libs.
Imagine que "dep2" en version 1.0 n'a pas la fonction "display" et que la 1.1 l'a.
En changeant de la 1.0 à la 1.1, tu vas entrainer un bug.
3. Les ouvertures de fichiers se font avec "with".
4. Eviter les variables globales. Encapsulé dans une classe, c'est mieux.
5. Essayer de cloisoner dans des fichiers ce qu'il faut éviter de mélanger :
- l'accès à l'inteface graphique
- la conf
- l'accès
- les opérations de bases
6. Un versioning digne de ce nom
7. Y'a des print ,des commentaires et des lignes de code commenté un peu partout.
J'aurais tendance à afficher les print dans un mode debug.
Les commentaires sont pas toujours intéressants.
Par exemple : # Programme principal : devant if __name__ == '__main__':
C'est valable pour tous les softs python donc pas besoin de le préciser.
Le code commenté, faut éviter et plutôt s'intéresser à des outils comme git qui permettent d'avoir l'historique du code et le différentiel.
La, on sait pas trop pourquoi c'est là : un code qu'on a oublié de supprimé, un test, une fonctionnalité avorté etc.
Je propose une branche rapide (refactoring) pour rectifier le tir (premier jet, faudra que je fasse une repasse dessus donc sans doute des régressions):
https://framagit.org/mothsart/handsup/tree/refactoring
Ça supprime déjà presque 650 lignes de code redondant.
Un autre point que je risque d'aborder dans un second temps : mettre en place des tests. (le point 5 évoqué précédemment permettra également de mettre ça en place)
C'est vachement sécurisant pour du dev et j'essai désormais d'en mettre partout et dès que je commence un projet.
Ya plusieurs choses qui me dérange dans ton soft.
Le but n'est bien évidement de critiquer mais de transmettre mon expérience et améliorer la maintenance/évolution du soft.
1. Les 4 variantes sont à 80 % du copié/collé.
C'est pas pratique pour faire évoluer ton soft. A chaque modifs, faut penser à le faire 4 fois.
Le mieux dans ce cas (en python) est de faire de l'héritage.
Une classe parente qui fait les opérations identiques et des classes enfants qui font avoir les opérations spécifiques.
2. Les imports avec des "*". Deux soucis liés à ça :
- ça va charger en mémoire des choses inutiles.
- ça peut occasionner des conflits de nom.
Ex : from dep1 import * et from dep2 import *
Toutes les 2 ont la fonction "display"
python plante quand on fait un "display()" car il sait pas laquel utilisé.
Avec des imports strictes, tu t'en rends compte dès le début et surtout tu évites des comportements bizarres quand tu fais des upgrades de libs.
Imagine que "dep2" en version 1.0 n'a pas la fonction "display" et que la 1.1 l'a.
En changeant de la 1.0 à la 1.1, tu vas entrainer un bug.
3. Les ouvertures de fichiers se font avec "with".
4. Eviter les variables globales. Encapsulé dans une classe, c'est mieux.
5. Essayer de cloisoner dans des fichiers ce qu'il faut éviter de mélanger :
- l'accès à l'inteface graphique
- la conf
- l'accès
- les opérations de bases
6. Un versioning digne de ce nom
7. Y'a des print ,des commentaires et des lignes de code commenté un peu partout.
J'aurais tendance à afficher les print dans un mode debug.
Les commentaires sont pas toujours intéressants.
Par exemple : # Programme principal : devant if __name__ == '__main__':
C'est valable pour tous les softs python donc pas besoin de le préciser.
Le code commenté, faut éviter et plutôt s'intéresser à des outils comme git qui permettent d'avoir l'historique du code et le différentiel.
La, on sait pas trop pourquoi c'est là : un code qu'on a oublié de supprimé, un test, une fonctionnalité avorté etc.
Je propose une branche rapide (refactoring) pour rectifier le tir (premier jet, faudra que je fasse une repasse dessus donc sans doute des régressions):
https://framagit.org/mothsart/handsup/tree/refactoring
Ça supprime déjà presque 650 lignes de code redondant.
Un autre point que je risque d'aborder dans un second temps : mettre en place des tests. (le point 5 évoqué précédemment permettra également de mettre ça en place)
C'est vachement sécurisant pour du dev et j'essai désormais d'en mettre partout et dès que je commence un projet.