Convention de nommage - Githubissues

streino commented 2 days ago

Un peu paumé dans la convention de nommage. Je lis ici "score de avg_quality" au lieu de "moyenne de quality->score". Au minimum, avg__quality__score ?

_Originally posted by @streino in https://github.com/ecolabdata/ecospheres-dashboard-backend/pull/7#discussion_r1805050980_

Mais j'ai l'impression qu'on ferait mieux d'utiliser la sémantique suivante :

-> devient _. Seul hic, pas de distinction entre quality->score et un champ dont le nom d'origine serait quality_score. Mais IMO si on est confronté à ce problème le nommage original est pourri.
__ utilisé pour séparer le nom du champ du "type" de calcul appliqué sur ce champ.
Post-fixer le nom du champ par le type de calcul, pour regrouper lexicalement toutes les infos disponibles sur un champ.

Ce qui donnerait : nom_de_champ__calcul. Ex : quality_score__mean, contact_point_name__exists, ...

abulte commented 2 days ago

J'aime quand même bien l'idée d'avoir l'info qu'on a été chercher la valeur dans un JSON nested.

Claude propose nom_de_champ__sous_champ__calcul.

streino commented 2 days ago

J'aime quand même bien l'idée d'avoir l'info qu'on a été chercher la valeur dans un JSON nested.

Claude propose nom_de_champ__sous_champ__calcul.

Il a pas osé le triple underscore ? :sweat_smile:

Ça me pose pas particulièrement de problème, mais en quoi ça serait utile de savoir qu'on l'a récupéré dans un champ json plutôt qu'un autre champ ? Savoir où chercher dans le modèle data.gouv (mouaif, y a pas tant de nesting) ? Autre chose ?

abulte commented 2 days ago

Yes faire le lien avec le modèle data.gouv.fr sans avoir à trop réfléchir. C'est peut-être pas indispensable mais je trouve ça confortable.

streino commented 2 days ago

Ok, on part là dessus alors ! Reste à gérer la migration en essayant de conserver l'historique des métriques.

ecolabdata / ecospheres-dashboard-backend

Convention de nommage #8