Django 日期命名约定
Django 中的“创建”和“上次编辑”日期是否有任何命名约定?
IE。在 Symfony 框架中,该字段默认命名为:
- created_at
- Updated_at
Is there any naming convention for "created" and "last edit" dates in Django?
ie. in Symfony Framework this fields are named by default:
- created_at
- updated_at
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
事实上,据我所知,Django 没有规范的约定,但我真的很喜欢 Rails 约定(我想这也启发了 Symphony):
created_at
for DateTime fieldscreated_on
对于日期字段created
对于创建日期来说效果很好,但是一旦您有更多不明确的字段(例如activated
),它就会成为一个问题。它是布尔值还是日期/日期时间?命名约定的存在是为了帮助开发人员更快地理解代码并减少在不重要的决策上浪费时间。这就是约定优于配置范式背后的哲学,它在 Rails 社区中很重要,但并不那么重要不幸的是在姜戈那里。例如,我提到的这种混乱是典型的,这就是为什么我更喜欢总是格外清楚:is_activated
activated_at
activate_on
我听人们说“你不应该将字段名称与数据类型混合在一起”,但在我看来,这似乎是一个相当空洞的提示,而且我从未听到过其背后的任何具体论点。如果我们想优化代码可读性和决策制定,那么我真的认为显式命名约定是正确的选择。
Indeed, as far as I can tell there's no canonical convention for Django, but I really like the Rails convention (which I suppose also inspired Symphony):
created_at
for DateTime fieldscreated_on
for Date fieldscreated
works fine for creation dates, but as soon as you have more ambiguous fields likeactivated
, it becomes a problem. Is it a boolean or a date/datetime? Naming conventions exist to help developers understand code faster and waste less time with unimportant decisions. That's the philosophy behind the Convention over Configuration paradigm, which is big in the Rails community but not as much in Django's unfortunately. This confusion I mentioned for example is typical and that's why I prefer to always be extra clear:is_activated
activated_at
activated_on
I've heard people say that "you shouldn't mix field names with data types" but it seems like a rather empty tip in my opinion and I've never heard any concrete argument behind it. If we want to optimize code readability and decision making then I really think explicit naming conventions are the way to go.
在 Django 原始模型中,该字段根据模型类型命名,即。
所以我们可能应该遵循这个约定。
In Django origin models this fields are named based on Model type ie.
So probably we should follow this convention.
我不认为 Django 中有类似规范的方式来命名这些东西。 PEP8 很好地涵盖了某些部分,主要是因为这类事情超出了 Django 的范围,因为它更多的是风格问题(也许还有内部惯例)。
也就是说,我认为将这些字段命名为
created_at
和updated_at
是很常见的,我个人在编写自己的代码时遵循此约定。我建议避免使用诸如created
或updated
这样的名称,因为它们不明确(尽管一些流行的 libs 使用该样式):它们是布尔值还是其他值?is_created
/is_updated
,如果您需要这些,是更好的选择。I don't think there's something like a canonical way of naming such things in Django. Some parts are well covered by PEP8, mostly because this sort of thing is out of scope of Django, since it's much more a matter of style (and maybe house conventions).
That said, I think it's pretty common to name these fields as
created_at
andupdated_at
, and I personally follow this convention when writing my own code. I advise to avoid names likecreated
orupdated
since they're ambiguous (although some popular libs use that style): are they booleans or something else?is_created
/is_updated
, if you need those, are better options.我更喜欢不带
_at
后缀的created
和updated
。我不知道命名字段有任何“规范”偏好。就其价值而言,我认为Rails 使用
created_at/created_on
和updated_at/updated_on
。I prefer
created
andupdated
without the_at
suffix. I don't know of any "canonical" preference for naming the fields.For what it is worth, I think Rails uses
created_at / created_on
andupdated_at / updated_on
.Django Model Utils 为此有一个模型混合,将它们命名为
created
和modified
——我建议使用他们的模型混合来轻松标准化模型和项目。Django Model Utils has a model mixin for this, naming them
created
andmodified
-- I recommend using their model mixin to easily standardize across of your models and projects.