10

What is a widely accepted 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"?

Are there any official or semi-official style guides that recommend such a format?

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".)

Improve this question
6
  • 5
    The generally accepted convention is StartDate. Use DateStarted if you want your date field names to cluster together when sorted, e.g. Intellisense. Commented Jan 11, 2018 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. Commented Jan 12, 2018 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. Commented Jan 12, 2018 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. Commented Jan 12, 2018 at 6:56
  • 1
    Another format that Laravel uses is StartedAt which is easy to comprehend and sounds quite natural. Commented Jan 12, 2018 at 16:03

4 Answers 4

Reset to default
5

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 of the content 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 with (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 than 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.

Improve this answer
7
  • 3
    "Start is not really a noun" -- No, but StartDate is. Commented Jan 11, 2018 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. Commented Jan 11, 2018 at 20:52
  • One or the other, for consistency. If you use StartDate, you should use ExpirationDate. Commented Jan 11, 2018 at 20:53
  • 1
    Why? Would love to read your rationale on why that consistency should overcome the other concerns I listed above. Commented Jan 11, 2018 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. Commented Jan 11, 2018 at 20:55
2

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.

Improve this answer
2
  • 1
    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? Commented Jan 12, 2018 at 14:36
  • 1
    Code is read much more than it is written, so names should optimize for clarity and readability, not for autocomplete tools. Commented Sep 23, 2021 at 12:57
1

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 ...

Improve this answer
2
  • So if the record in question has only one "kind" of range dates you would use simply "From" and "Until" even if the user thinks of these values as "Start" and "End"? Commented Jan 11, 2018 at 20:51
  • By the way, I might be tempted to use till instead of until english.stackexchange.com/questions/6989/… ;) Commented Jan 12, 2018 at 14:33
0

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.

Improve this answer
3
  • So, in my example, you would go with simply Start? Commented Jan 12, 2018 at 14:31
  • @PatrickSzalapski: By no means; I would use StartDate or some_time_periodStart Commented Jan 12, 2018 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). Commented Jan 12, 2018 at 17:13

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.