What is a good naming convention for date variables or properties in an Object-based, strongly typed language like C# (and by extension, for date database columns)? Do you use the word "date"?

I'm going to avoid an example with the canonical "created" or "updated" date/time properties, and instead pick another common example: assuming there is no technical, domain-specific, or user reason to avoid any of these names, what would you name a property that contains the date that an interval (a period of calendar time) started or will start?

  • StartDate
  • StartedDate
  • DateStarted
  • DateStart
  • DateOfStart
  • Started
  • Starts
  • Start

(This question could also be asked for date-time properties, presumably using "Time" instead of "Date".)

closed as primarily opinion-based by gnat, Jarrod Roberson, Bart van Ingen Schenau, David Arno, 17 of 26 Jan 12 '18 at 13:07

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.

  • 4
    The generally accepted convention is StartDate. Use DateStarted if you want your date field names to cluster together when sorted, e.g. Intellisense. – Robert Harvey Jan 11 '18 at 20:51
  • 1
    @Robert Harvey Since VS2010 the clustering in IntelliSense is hardly an issue anymore, it will just show items containing the search term, not just the ones starting with it. I find myself going with timeStarted style though, mainly because in declaration sections the preferred style looks garbled. If one starts with the type they align and the discriminating parts will pop out. – Martin Maat Jan 12 '18 at 6:43
  • 1
    Note that just "Started" looks like an event for which the convention says something has just Started, as opposed to Starting, meaning it is about to start. – Martin Maat Jan 12 '18 at 6:48
  • 1
    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. – Jarrod Roberson Jan 12 '18 at 6:56
  • Another format that Laravel uses is StartedAt which is easy to comprehend and sounds quite natural. – mitchdav Jan 12 '18 at 16:03

I can see pros and cons to all of these. Concerns I thought of:

  • Should the name make it clear this is a date, or is that already implied from the type?
  • Should the name be recognizable as a date when in a list of property names?
  • Should the name end with the noun that hints at the essence of the value?
  • Do non-intuitive token orderings matter, such as orderings that are rare or unused in English?
  • Does tense matter?
  • Should we be concerned that all such properties sit near each other when ordered?
  • Can the simplicity of a property name outweigh vagueness due to that simplicity?

My first judgment is to answer as follows, but I still want more opinions from experience.

  • The name should make it clear that it is a date, as the name itself should capture the essence content of the value stored. (in other words, we know that a property like Name is very likely a string because names are strings, but a property like Start leaves us thinking, "start...what?"
  • The name should end (or entirely consist of) a noun that hints at the essence of the value stored.
  • Simplicity in naming is good but not paramount.
  • Avoid non-inituitive token (word) orderings; prefer the natural language-ordering of tokens.
  • Past tense should be avoided for any value that is not always in the past.
  • Ordering of properties by name should be less of a concern then naming it well by the above principles.

Those judgments lead me to choose StartDate as the best choice in the example given.

Start is not really a noun, but for other examples, I might consider a noun alone without "...Date" for simplicity if there would be no confusion--for example, Expiration rather than ExpirationDate. For further simplicity, I might consider a verb form too--for example, Expires rather than Expiration. But now I feel like I am drifting into "whatever feels good" rather than having a coherent standard.

Would love to hear from anyone to help clarify.

  • 3
    "Start is not really a noun" -- No, but StartDate is. – Robert Harvey Jan 11 '18 at 20:49
  • Right, which is why I would use StartDate and probably never Start, but I would also consider using Expiration rather than ExpirationDate. – Patrick Szalapski Jan 11 '18 at 20:52
  • One or the other, for consistency. If you use StartDate, you should use ExpirationDate. – Robert Harvey Jan 11 '18 at 20:53
  • 1
    Why? Would love to read your rationale on why that consistency should overcome the other concerns I listed above. – Patrick Szalapski Jan 11 '18 at 20:54
  • 2
    When talking about coding style, consistency overrides almost all other considerations, to the point that you should probably follow the coding style of your shop, even if some parts of it don't make sense to you. – Robert Harvey Jan 11 '18 at 20:55

I like the comment about using the word Date as the prefix so that Intellisense-style auto-complete will work better.

One thing to be aware of then is that DateStart and DateStarted are not semantically equivalent in English. One, the former, implies that the date has not arrived but that the point is upcoming in the future. The latter, DateStarted, implies that the thing has in fact started and at that specific time. Depending on what your system is trying to accomplish you may need both fields.

  • DateStart really irks me as awkward and unnatural token order, so to follow your principle, I might go to DateOfStart. Also: Do we really want to name things for the sake of AutoComplete making edits a bit easier, or should we instead name things for easiest understanding of current and future developers? – Patrick Szalapski Jan 12 '18 at 14:36

I split date fields into two categories

a) Those that just represent a single point in time are always xxxDate - e.g. OrderDate, InvoiceDate, BirthDate, EnrolmentDate ...

b) Those that represent the start or end point of a time range are always xxxFrom or xxxUntil, even for those classes or records that only hold one end of the range - e.g. PriceApplicableFrom, DiscountValidUntil ...


The way I always try to do it is to differentiate dates (and times) from time spans, based on their context in the problem domain.

For example, a Date value would represent a specific point in time that is of interest in the problem domain -- an OrderDate, an employee StartDate, etc. Any time span before or after these specific points in time is not relevant in the problem domain as a time span. These kinds of values I always call somethingDate.

For spans of time that are relevant in the problem domain -- as time spans -- then I name the end points of the time span somethingStart / somethingStop, or somethingBegin / somethingEnd, where the "something" is a term in the problem domain that represents a span of time. For example, FallTermBegin / FallTermEnd, or FlightTimeStart / FlightTimeStop.

Since the domain term itself signifies a span of time, you don't have to include Date or Time in the variable name, since you already know its nature. Also, if you give sufficient attention to the name of the domain time span, the units are usually intuitive as well, like hours for FlightTime or days for FallTerm.

  • So, in my example, you would go with simply Start? – Patrick Szalapski Jan 12 '18 at 14:31
  • @PatrickSzalapski: By no means; I would use StartDate or some_time_periodStart – Mark Benningfield Jan 12 '18 at 17:05
  • @PatrickSzalapski: Don't worry so much about the grammatical sense (noun / verb), and concentrate on the semantic sense (point in time / time period). – Mark Benningfield Jan 12 '18 at 17:13

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