Django 日期命名约定

发布于 2024-09-24 00:15:03 字数 129 浏览 3 评论 0原文

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

浅浅 2024-10-01 00:15:03

事实上,据我所知,Django 没有规范的约定,但我真的很喜欢 Rails 约定(我想这也启发了 Symphony):

  • created_at for DateTime fields
  • created_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 fields
  • created_on for Date fields

created works fine for creation dates, but as soon as you have more ambiguous fields like activated, 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:

  • If it's a boolean is_activated
  • If it's datetime activated_at
  • If it's just a date 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.

染年凉城似染瑾 2024-10-01 00:15:03

在 Django 原始模型中,该字段根据模型类型命名,即。

  • auth.User:date_joined
  • comments.Comment:submit_date

所以我们可能应该遵循这个约定。

In Django origin models this fields are named based on Model type ie.

  • auth.User: date_joined
  • comments.Comment: submit_date

So probably we should follow this convention.

我为君王 2024-10-01 00:15:03

我不认为 Django 中有类似规范的方式来命名这些东西。 PEP8 很好地涵盖了某些部分,主要是因为这类事情超出了 Django 的范围,因为它更多的是风格问题(也许还有内部惯例)。

也就是说,我认为将这些字段命名为 created_atupdated_at 是很常见的,我个人在编写自己的代码时遵循此约定。我建议避免使用诸如 createdupdated 这样的名称,因为它们不明确(尽管一些流行的 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 and updated_at, and I personally follow this convention when writing my own code. I advise to avoid names like created or updated 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.

-小熊_ 2024-10-01 00:15:03

我更喜欢不带 _at 后缀的 createdupdated。我不知道命名字段有任何“规范”偏好。

就其价值而言,我认为Rails 使用created_at/created_onupdated_at/updated_on

I prefer created and updated 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 and updated_at / updated_on.

哽咽笑 2024-10-01 00:15:03

Django Model Utils 为此有一个模型混合,将它们命名为createdmodified——我建议使用他们的模型混合来轻松标准化模型和项目。

Django Model Utils has a model mixin for this, naming them created and modified -- I recommend using their model mixin to easily standardize across of your models and projects.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文