[Location] Statistiques d'un club #44
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Sulley/khana#44
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Je vais surtout aborder la fonction
club_statistics
, dans la mesure où elle fait pratiquement 150 lignes (soit, 10x plus que ce que recommanderait Roel :-p).Modèle
<- ce passage-ci fait penser qu'il manque un
related_name
entreClub
etCourse
, et unorder_by
par défaut au niveau de la classeCourse
.Nomenclature
De manière générale, dans la fonction, essaie de respecter la nomenclature:
courseList
->courses_list
totalHoursPaidForCourse
->total_hours_paid
(et comme on est dans le contexte du cours, je ne pense pas qu'il soit utile de spécifier le suffixe)totalCourses
->number_of_courses
Un autre point concerne la sémantique:
Donc, l'idée est d'ajouter des secondes à une variable qui s'appelle
totalHoursByWeek
.Tout à la fin, tu divises la valeur obtenue par 3600.
On a tous voté dans ma tête, et c'est non.
Structures
Tu as un dictionaire qui reprend la liste des gymnastes
gymnastsDict = {}
.Pour chaque cours, tu as l'air de construire un ensemble de gymnastes:
Le gros bloc ci-dessous laisse penser que tu as besoin d'une structure, avec des attributs par défaut:
->
Tu as aussi un bloc (lignes 235-236):
Mais en gros, tu n'utilises après que la variable
nbattendance
.Autant faire directement un
count
sur le queryset, sans quoi la liste complète est évaluée à chaque tour de boucle. Le résultat peut sans doute être passé directement au constructeur de la classeGymnastStatistics
dont il est question ci-dessus.Ensuite, il suffit de créer une méthode
add_course
sur la classe ci-dessus pour gérer toutes les lignes suivantes:Cela évitera aussi de jongler avec les clés du dictionnaire, puisque ce seront de "vrais" attributs définis au niveau de la classe.
Structures ²
Le dernier passage, ce sont les lignes 257-292. Tu peux les simplifier en ajoutant toutes ces informations au niveau de la classe
GymnastStatistics
, avec un mécanisme de getter/setter si tu le juges nécessaire, ou simplement via une méthodeexport
outo_dict
ou ... qui renverrait ces données, calculées sur base des attributs de la classe.Typiquement:
pourra se résumer avec une méthode (ou un getter) type
qui sera un chouia plus lisible ;-)
Refactoring
De la ligne 177 à la ligne 204, tu te trouves dans une boucle, où, pour chaque cours, tu calcules un ensemble d'informations.
Sors ces données et fais-en une méthode du modèle
Course
. Cela allégera énormément la lecture et simplifiera également la gestion du code.Waouw… Tu penses qu'il y aurait moyen de découper ce ticket en plusieurs "sous-ticket"s ? Parce que la c'est long… Mais je vais commencer à y travailler dessus.
Oui, en fonction des grands titres.
Le plus long concerne la première structure.
Mais c'est surtout parce que c'est plus grand morceau de code ;-)