salut,
Bon alors j ai quelques détails technique et de conception a te dire.
Déjà je ne comprends pas trop cette obsession a faire un tableau proche de ceux des base de données sans avoir les avantage de ces derniers (possibilités de requêtes, performances élevé,...).
En effet aujourd'hui les genres font de plus en plus d'ORM pour profiter du monde objet des langages avec une source de donnée relationnel.
Mais ici on semble faire l'inverse, ramener les vieux tableaux dans le monde objet.
En effet personnellement j'aurai tout simplement utiliser un tableau d'objet (chaque objet représentant une ligne et chaque attribut représentant un entré de la colonne), a la rigueur si tu veux une recherche approfondi sur les objet on aurai pu encapsuler ca dans une classe et rajouter une méthode find() qui irai chercher dans les attributs des objets.
Sinon en cas de réél besoin de tableau comme dans les base de données avec de puissantes methode de recherche j’aurai utilisé sqlite avec une base stocké en mémoire et un coup de sqlobject par dessus à la rigueur.
Sinon d’un point de vue implémentation il y a quelques problèmes.
Déjà au niveau formalisme : les commentaires ne s’écrivent pas comme ca en python.
Il faut mettre """ """ au début de chaque membre (module, classe, …)
Ya des normes de notation assez importante comme la notation des classe avec des majuscule (MyClass, pas myclass)
Ensuite au niveau notation des variables c assez souvent illisible.
En général on ne met pas de type dans le nom de la variable et surtout pas que le type (comme le dicco et dico qui se suivent, ind_l et ind__l, berk !!) mais on doit le décrire en quelque mot. Sinon par exemple le dico_ref_l n’aurai pas été plus lisible en écrivant simplement "lines" ?
A cause de cette illisibilité je n ai pas poussé la lecture à fond, c’est vraiment un élément important dans le cas de partage de code.
Ensuite j ai vu certaines chose inutile :
1
2
| a = 0
for a in self.dico_ref_c.keys() : |
Inutile d’initialisé a il va prendre toutes les valeurs des clefs.
Je n’ai pas bien compris l’utilisation de 2 dictionnaires pour les colonnes et les lignes …
En effet tu utilise comme ligne un int que tu transforme en string et que tu incrémente a chaque fois … je ne vois pas bien l’intérêt de ce genre de clef dans un dictionnaire dont le principe est d’avoir un clef pertinente. Dans ce cas autant utiliser un tableau de tableau qui sera toujours organisé sur des clefs d’int ascendante dans les colonnes et les lignes, les manipulations dans la suite aurai été BEAUCOUP plus simple et cela aurai fait gagner un paquet de ligne de code.
Je trouve les utilisation de globals() partout archi degueulasse et encore une fois peu lisible.
Si on parle des perf, je pense qu’il y a un gouffre de performance un peu partout :
- L’utilisation massive de dictionnaire la ou il ne faut pas (les dictionnaires avec comme index des int qui s’incrémente)
- L’utilisation massive de global()[str]
- L’enchainement des " a " + " b " + " c " + … dans la création des strings (au lieu d’utiliser des format)
Sinon inutil de faire :
1
2
| dicco = [self.dico_ref_l[a], self.dico_ref_c[b]]
dico.append(dicco) |
autant faire
dico.append([self.dico_ref_l[a], self.dico_ref_c[b]])
Bon voila j’espère que tu prendra pas mal la critique et bon courage pour ton jeu 
[module] intermédiaire en base de donnée et dictionnaire
Répondre avec citation
Envoyé par alexdevl
Partager