If I have a class that stores a DateTime:
class LogEntry
{
readonly DateTime dateTime;
public LogEntry(DateTime dateTime)
{
this.dateTime = dateTime;
}
public DateTime ?????
{
get
{
return dateTime;
}
}
}
What should I name the DateTime property? Or shoul开发者_如何学Cd I split the property into 2 properties: 1) Date 2) Time?
edit: I was looking for a property name that provides inference that its value is both a date and a time, not a property specific to log entries (e.g., DateCreated doesn't provide any inference that it also shares the time the entry was created and vice versa).
TimeStamp
maybe?
LogDate
CreatedDate
EntryDate
StarDate // **
Pick a name that you feel describes the property best. And, no, do not split the property.
When
is a good name in a log.
Edit: and from the offical naming guidlines: "Do consider to name a property the same as its Type." That results in
public DateTime DateTime { get { ... } }
Assuming LogEntry
is used for logging, here is how some other logging platforms do it:
log4net calls it TimeStamp
in the LoggingEvent class.
NLog calls it TimeStamp
in the LogEventInfo class.
Enterprise Library calls it TimeStamp
in the LogEntry class.
Microsoft calls it DateTime
in the TraceEventCache class.
(TraceEventCache
is passed into TraceListener
Trace*
calls. DateTime
is the time at which the logging message was generated.)
Anything that's simple, doesn't conflict with other names such as DateTime
itself, and is descriptive. Since it's a log entry, you could call it EntryTime
.
Unlike most suggestions here, I'd use DateCreated
because it's intuitive to start typing "date" when you look for the creation date. I also don't think there's a problem only "date" appears in the name and not "time". That's frequent and acceptable.
What aboutTimeStamp
?
You should pick a convention for timestamps in your code base and then stick to that. For example, I call all my timestamps "updated_at" or "created_at". Other options would be CreatedDate and UpdateDate.
Don't split Date and Time into separate properties. The only reason you would do that would be for some kind of optimization for high volume processing where you explicitly identify Date parsing as a bottleneck.
Whatever makes sense to you (and your team). You could use EntryDateTime
as that would make sense. If you're ever going to need the date and time separate, then it would be worth creating separate methods, but there's no need to split the two simply for naming reasons.
You should pick a descriptive name as what the property does...
If its for a CreateDate then "CreateDate".. pretty self explanatory.
For logging, you can use "LoggedTimeStamp", "LoggedDateTime" etc.
A date is just a coarse grain measure of Time, that lumps 24 hours into the same unit. Put in terms of chickens and eggs, Time comes before date: Time is the physical entity, date is just a unit of measurement. The DateTime datatype helps confuse the issue and leads many people to think of Time as a fraction of Date. This is completely wrong! Einstein didn't talk of Space Date, did he?
Your names should be descriptive of what actually happens, as opposed to detailing the data type (Lezinski, or whatever his name, clearly didn't have intellisense at his disposal).
So either LogTime or EntryTime would be the best names.
Confusing the datatype, the unit of measurement and the physical entity are conceptual errors that lead programmers up the garden path.
And it ain't the garden of Eden.
The comment on the question says that the question shouldn't be class specific.
The correct answer though is class specific, it doesn't relate to the fact that the property is a DateTime (we already know that it's a date and time because, well, because it is a data and time). The property will exist for a particular reason, and it is that reason that we should consider when naming.
Still, while a request for a non-class specific property name is being made, I offer:
public DateTime TheMomentOfTruth
:)
精彩评论