I am using a lot of DateTimes in my application. Now I usually name it like StartDateTime, EndDateTime, etc, to imply there is also a time involved.

I am getting a bit tired of this (it is tiresome to read), and most of the time it is quite logical there is a time compartment to it anyway.

Now I'm thinking about ditching StartDateTime in favor of the shorter StartDate, despite that there is also a time part included.


What is better: easier to read vs being more explicit about that there is a time included?

(ps: I guess this has a lot to do with C# not having separate objects for Date and DateTime, so that's where the need for Hungarian comes from)

closed as primarily opinion-based by gnat, Telastyn, GlenH7, user40980, Kilian Foth Aug 6 '14 at 10:44

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
  • In my experience, you'll use DateTimeOffset more than the calendar focused DateTime. – Telastyn Aug 5 '14 at 14:31
  • For DateTimes, I name it corresponding to what I am going to use. So if I won't ever care about the time, I call it StartDate. If the time is what's important, I call it StartTime. StartDateTime is for when I care about both fields. – Bobo Aug 5 '14 at 18:07
  • 2
    Note that including the datatype is "Systems" Hungarian Notation, and is generally accepted as bad practice (let the IDE tell you instead of cluttering up variable names). "Apps" Hungarian on the other hand - using the semantic meaning - is considered "good" practice (use it for things the IDE won't tell you). For example, instead of Start, StartDate, or StartDateTime, why not ProjectStart? – Izkata Aug 5 '14 at 18:37

I would generally expect DateTime objects, so I would go with Start and End if they were datetimes and allow people who are in doubt to check the type definition, intellisense or documents.

It seems logical to prefer the more specific StartDate and EndDate for cases where you have only a date, which is more likely to be a special case.

As a general rule, I prefer not to include the type in my variable names unless it is going to behave in an unexpected way. Where possible I try to find ways to avoid variables that behave in unexpected ways.

  • One such special case is when you have a DateTime object but are effectively ignoring either the Date or Time components. – Bart van Ingen Schenau Aug 5 '14 at 14:35
  • Putting the type in the name doesn't feel right but as @Bart mentioned sometimes it cannot be avoided. – ChaosPandion Aug 5 '14 at 14:38
  • 1
    It depends a lot on the system- if I am in control of the code, I would avoid using a DateTime and then ignoring part of it, but sadly one isn't always in sufficient control to enforce even the most rational of whims. I find it particularly irritating when I have to go against good practice to fit in with another library, but often one can limit this to the library calls rather than allowing it to pervade our own code. – glenatron Aug 5 '14 at 14:42
  • 1
    Hmm even skipping the Date part. Interesting. Might be an option. I do have the feeling it might clash in the future between a property Start and the verb Start() though. – Dirk Boer Aug 5 '14 at 14:45
  • 2
    You certainly wouldn't want a property and method with the same name, but depending on what you want start to mean you can name accordingly - Started if it is a record, StartAt if it is a schedule and so on. Or change Start() to Begin(), Commence(), Initiate() and so on :) – glenatron Aug 5 '14 at 14:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.