existe-t-il une convention de dénomination pour les dates "créées" et "Dernières modifications" à Django?
IE. Dans Symfony Framework, ces champs sont nommés par défaut:
5 Réponses :
Je préfère Pour ce que cela vaut, je pense rails utilise créé et mis à jour sans le _at suffixe. Je ne connais aucune préférence "Canonicale" pour nommer les champs.
créé_at / créé_on et mise à jour_at / mise à jour_on .
dans les modèles d'origine Django Ces champs sont nommés en fonction du type de modèle IE.
Donc, probablement, nous devrions suivre cette convention.
En fait, cela semble être plutôt incompatible. Pourquoi ne pas avoir soit date_joined et date_submited ou join_date et soumettre_date ?
À mon avis, ce n'est pas une convention, mais une preuve qu'il n'y a pas de convention.
De plus, il y a last_login dans abstractbasesopeUser ( django.contrib.auth.base_user ) qui est encore plus incohérent.
En effet, autant que je sache, il n'y a pas de convention canonique pour Django, mais j'aime beaucoup la convention de rails (que je suppose également inspiré la symphonie):
créé_at pour les champs DateTime
-
créé_on pour les champs de date
créé fonctionne bien pour la création dates, mais dès que vous avez plus de champs ambiguës tels que activé , cela devient un problème. Est-ce un booléen ou une date / datetime? Il existe des conventions de dénomination pour aider les développeurs à comprendre le code plus rapidement et à perdre moins de temps avec des décisions sans importance. C'est la philosophie derrière le Convention sur la configuration paradigme, qui est grand dans la communauté des rails mais pas aussi Beaucoup de Django malheureusement. Cette confusion que j'ai mentionnée par exemple est typique et c'est pourquoi je préfère toujours être très clair:
- Si c'est un booléen
is_activé
- Si c'est DateTime
activé_at
- Si c'est juste une date
activé_on
J'ai entendu que les gens disent que "vous ne devriez pas mélanger les noms de champ avec des types de données" mais cela ressemble à une pointe plutôt vide à mon avis et que je n'ai jamais entendu aucun argument concret derrière cela. Si nous voulons optimiser la lisibilité du code et la prise de décision, je pense vraiment que les conventions de nommage explicites sont la voie à suivre.
Une autre façon de le regarder, c'est que cela vous permet de tirer parti de la typage dynamique. La signification du champ reste la même chose, mais la précision varie entre "Oui", "Oui, ce jour-là" et "Oui, ce jour-là et cette heure". «Non» et 'Jamais' signifient essentiellement la même chose.
En fait, Django a beaucoup de conventions (comme la convention de l'application du code d'organisation), mais je crois que "nommer des choses" est hors de portée de Django (PEP8 peut-être?)
Bien sûr, Django a des conventions, je ne dis pas que ça ne le dit pas. Je dis simplement que la philosophie de la définition et du respect des conventions n'est pas aussi importante / explicite que dans la communauté des rails, par exemple. Je ne suis pas sûr que cela figure dans la portée de Pep8 car, comme je le percevoir, c'est un problème qui arrête principalement dans le contexte des ormes. En fait, je dirais que c'est plus un problème de base de données qu'un Python. Mais c'est juste une observation empirique, je ne dis pas que c'est nécessairement une question de DB dans la nature, mais je pense qu'une convention de DB est plus urgente que celle du niveau Python en général ...
Je ne pense pas qu'il y ait quelque chose comme un Canonical Way de nommer de telles choses à Django. Certaines parties sont bien recouvertes de Pep8 , principalement parce que Ce genre de chose est hors de portée de Django, puisque c'est beaucoup plus une question de style (et peut-être des conventions de maison).
Cela dit, je pense qu'il est assez courant de nommer ces champs comme créé_at et mise à jour_at , et je suis personnellement suivi de cette convention lors de la rédaction de mon propre code. Je conseille d'éviter les noms tels que créé ou mis à jour car ils sont ambigus (bien que certains libs Utilisez ce style): sont-ils booléens ou autre chose? is_created / is_updated , si vous en avez besoin, sont de meilleures options.
Django Modèle Utils a un modèle MixIn Pour cela, nommez-les créé et modifié - je vous recommande d'utiliser leur modèle Mixin pour normaliser facilement sur vos modèles et projets.
Comme il n'y a pas de directive officielle de Django sur la dénomination des conventions, cela devrait vraiment être un wiki communautaire.