Django日期命名规范

Question

在Django中，“创建日期”和“最后编辑日期”的命名规则是什么？例如，在Symfony框架中，这些字段默认命名为：created_at和updated_at。

- Tomasz Wysocki

---

由于Django官方没有关于命名规范的官方指南，所以这应该是社区Wiki。 - Ben James

Answer 1

实际上，据我所知，Django没有规范的约定，但我真的很喜欢Rails的约定（我想Symphony也受到了启发）：

• created_at用于DateTime字段
• created_on用于Date字段

created对于创建日期很好用，但是一旦出现更加模糊的字段，比如activated，它就成为了一个问题。它是布尔值还是日期/时间？命名约定存在的目的是帮助开发人员更快地理解代码，并减少在不重要的决策上浪费时间。这就是约定优于配置范式的哲学，它在Rails社区中非常流行，但在Django中不太流行。例如，我提到的这种混淆是典型的，这就是为什么我总是更加清晰明了：

• 如果是布尔值，使用is_activated
• 如果是日期时间，使用activated_at
• 如果只是日期，使用activated_on

我听人们说过“不要在字段名称和数据类型中混合”，但我认为这只是一个空洞的提示，而且我从未听说有任何具体的论点支持它。如果我们想要优化代码的可读性和决策能力，那么我真的认为明确的命名约定是正确的方式。

- Ariel

---

另一种看待它的方式是，它允许您利用动态类型。字段的含义保持不变，但准确性在“是”，“是，在这一天”和“是，在这一天和那个时间”的变化之间变化。 “否”和“从不”基本上意思相同。 - Thijs van Dien

实际上，Django有很多约定（如应用程序规范），但我认为“命名事物”超出了Django的范围（也许是PEP8？） - Lucas Sampaio

当然，Django确实有一些约定俗成的规则，我并不是说没有。但是，我只是想说，在定义和尊重这些规则的哲学上，与Rails社区相比，Django并没有那么重要/明确。我不确定这是否属于PEP8的范畴，因为我认为这主要是在ORM的背景下出现的问题。事实上，我认为这更多地是一个数据库问题，而不是Python问题。但这只是一种经验性的观察，我并不是说它本质上一定是数据库问题，只是我认为DB的约定比通常在Python层面上制定的约定更加紧迫... - Ariel

Answer 2

我认为在Django中没有像命名规范这样的“标准方式”。一些部分已经被PEP8很好地覆盖，主要是因为这种事情不在Django的范围内，因为这更多是一个风格问题（也许是公司惯例）。

话虽如此，我认为将这些字段命名为created_at和updated_at相当普遍，我个人在编写自己的代码时也遵循这个惯例。我建议避免使用created或updated这样的名称，因为它们含义不明确（尽管一些流行的库使用这种风格）：它们是布尔值还是其他什么？如果需要，is_created/is_updated是更好的选择。

- Lucas Sampaio

Answer 3

在Django的原始模型中，这些字段是基于模型类型命名的，例如：

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

因此，我们应该遵循这个约定。

- Tomasz Wysocki

---

事实上，这似乎有些不一致。为什么不使用date_joined和date_submitted或join_date和submit_date中的任何一个？ - Thijs van Dien

我认为这不是一种传统，而是证明没有惯例的证据。 - Ariel

还有在 AbstractBaseUser (django.contrib.auth.base_user) 中的 last_login，这甚至更加不一致。 - pawel

Answer 4

我更喜欢使用created和updated而不带有_at后缀。我不知道命名字段的任何“规范”偏好。

值得一提的是，我认为Rails使用created_at / created_on和updated_at / updated_on。

- Manoj Govindan

Answer 5

Django Model Utils提供了一个模型mixin，将它们命名为created和modified -- 我建议使用他们的模型mixin来轻松地在您的所有模型和项目中进行标准化。

- Mark Chackerian