4

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.

Question

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)

Improve this question
4
  • 1
    meta.programmers.stackexchange.com/questions/6582/… Commented Aug 5, 2014 at 14:27
  • In my experience, you'll use DateTimeOffset more than the calendar focused DateTime. Commented Aug 5, 2014 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. Commented Aug 5, 2014 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? Commented Aug 5, 2014 at 18:37

1 Answer 1

Reset to default
7

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.

Improve this answer
5
  • One such special case is when you have a DateTime object but are effectively ignoring either the Date or Time components. Commented Aug 5, 2014 at 14:35
  • Putting the type in the name doesn't feel right but as @Bart mentioned sometimes it cannot be avoided. Commented Aug 5, 2014 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. Commented Aug 5, 2014 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. Commented Aug 5, 2014 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 :) Commented Aug 5, 2014 at 14:48

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.