问题
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 should 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).
回答1:
TimeStamp
maybe?
回答2:
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 { ... } }
回答3:
LogDate
CreatedDate
EntryDate
StarDate // **
Pick a name that you feel describes the property best. And, no, do not split the property.
回答4:
Assuming LogEntry is used for logging, here is how some other logging platforms do it:
log4net calls it TimeStamp in the LoggingEventData struct.
NLog calls it TimStamp 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).
回答5:
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
.
回答6:
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.
回答7:
What aboutTimeStamp
?
回答8:
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.
回答9:
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.
回答10:
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.
回答11:
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.
回答12:
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
:)
来源:https://stackoverflow.com/questions/3867574/what-should-i-name-a-datetime-property