Question

如果我有一个存储DateTime的类：

class LogEntry
{
    readonly DateTime dateTime;

    public LogEntry(DateTime dateTime)
    {
        this.dateTime = dateTime;
    }

    public DateTime ?????
    {
        get
        {
            return dateTime;
        }
    }
}

我应该为DateTime属性命名什么？或者我应该将属性拆分为2个属性：1）日期2）时间？

编辑：我正在寻找一个属性名称，该名称提供推断，其值既是日期又是时间，而不是特定于日志条目的属性（例如，DateCreated不提供任何推断，它也分享时间条目已创建，反之亦然。）

Answer 1

TimeStamp也许？

Answer 2

When是日志中的一个好名字。

编辑：从正式命名指南：“执行考虑将属性命名为与其类型相同。” 这导致

 public DateTime DateTime { get { ... } }

Answer 3

LogDate
CreatedDate
EntryDate
StarDate // **

选择一个您认为最能描述该属性的名称。而且，不，不要拆分财产。

Answer 4

假设使用LogEntry进行日志记录，以下是其他一些日志记录平台的用法：

log4net在LoggingEventData结构中将其称为TimeStamp。

NLog在LogEventInfo课程中将其称为TimStamp。

Enterprise Library在LogEntry类中将其称为timeStamp。

Microsoft在TraceEventCache类中调用DateTime（TraceEventCache传递给TraceListener Trace *调用.DateTime是生成日志消息的时间）。

Answer 5

任何简单的事情都不会与DateTime本身等其他名称发生冲突，并且具有描述性。由于它是一个日志条目，您可以将其称为EntryTime。

Answer 6

与此处的大多数建议不同，我使用DateCreated因为在查找创建日期时开始输入“日期”是直观的。我也不认为只有“日期”出现在名称中，而不是“时间”。这是经常和可接受的。

Answer 7

TimeStamp怎么样？

Answer 8

您应该在代码库中选择时间戳的约定，然后坚持下去。例如，我将所有时间戳都调用为“updated_at”或“created_at”。其他选项包括CreatedDate和UpdateDate。

不要将日期和时间拆分为单独的属性。您这样做的唯一原因是对于高容量处理进行某种优化，您明确将日期解析标识为瓶颈。

Answer 9

对你（和你的团队）有什么意义。您可以使用EntryDateTime，因为这是有意义的。如果您需要将日期和时间分开，那么创建单独的方法是值得的，但是没有必要仅仅为了命名原因而拆分这两个方法。

Answer 10

您应该选择一个描述性名称作为该属性的内容......

如果它是CreateDate，那么“CreateDate”......非常自我解释。

对于日志记录，您可以使用“LoggedTimeStamp”，“LoggedDateTime”等。

Answer 11

日期只是时间的粗粒度量，它将24小时混合到同一个单位中。以鸡和蛋为例，时间在日期之前：时间是物理实体，日期只是一个度量单位。 DateTime数据类型有助于混淆问题，并导致许多人将Time视为Date的一小部分。这是完全错误的！爱因斯坦没有谈论太空日期，是吗？

你的名字应该描述实际发生的事情，而不是详细说明数据类型（Lezinski，或者他的名字，显然他没有智能感知）。

因此LogTime或EntryTime都是最好的名字。

混淆数据类型，测量单位和物理实体是导致程序员走上花园路径的概念错误。

它不是伊甸园。

Answer 12

对该问题的评论说，这个问题不应该是针对特定阶级的。

正确答案虽然是特定于类，但它与属性是DateTime这一事实无关（我们已经知道它是一个日期和时间，因为它是一个数据和时间）。该属性将由于特定原因而存在，这就是我们在命名时应该考虑的原因。

尽管如此，在提出非特定属性名称的请求时，我提供：

public DateTime TheMomentOfTruth

：）

我应该为DateTime属性命名什么？

12 个答案: