Naming convention for date properties [duplicate]

Question

This is not so much a question but a request for comments.

I've always hated the inclusion of the the date in a named property or variable that is a type of date or datetime. For example:

DateTime DateFileOpened {get; set;}

To me it seems that I'm including the data type in the variable name.

What I've settled on is a to use the word 'When' in place of date, For example

DateTime WhenFileOpened {get; set;}

Generally, I've stolen this from the use of Is or Has in boolean variables/properties.

So the question is: Does anybody have a better naming convention for dates?

Answer 1

The MSDN naming conventions for properties provide that the name of the property should be a noun or noun phrase, a criteria that DateFileOpened satisfies but WhenFileOpened does not.

It can help in these cases to check the property names used by the core .NET framework classes. The following code will extract the names of all properties of type DateTime from all loaded assemblies:

foreach (var v in AppDomain.CurrentDomain.GetAssemblies()
    .SelectMany(a=>a.GetTypes())
    .Where(a=>a.IsClass)
    .SelectMany(a=>a.GetProperties())
    .Where(a=>a.PropertyType == typeof(DateTime)))
          Console.WriteLine("{0}.{1}", v.DeclaringType, v.Name);

The output shows several conventions in place.

1. ______Date, ____Time (Examples: System.Net.Mime.ContentDisposition.CreationDate, System.Net.HttpWebRequest.Date, System.Timers.ElapsedEventArgs.SignalTime). The use of Date by itself can be confusing when both a date and time can be returned, but Time by itself can be considered less ambiguous. (A property that returns a time without a date would have a return type of TimeSpan rather than DateTime.)

2. _____DateTime, _____TimeStamp. (Examples: System.Globalization.GregorianCalendar.MinSupportedDateTime, System.Diagnostics.TraceEventCache.DateTime, System.Net.Cookie.Timestamp). This convention is verbose, but it is unambiguous that the entire timestamp (Date+Time) is intended.

3. Neither. (Examples: System.Net.FtpWebResponse.LastModified, System.Globalization.DaylightTime.Start, System.Net.Cookie.Expires). Not including the return type in the name is consistent with most property names (String.Length, not String.LengthInt).

Since there is no consistent approach, any of these patterns may be deemed acceptable.

As a matter of preference, however, DateFileOpened suggests that a file can only be opened once. If this is not the case, a property name like FileLastOpened or even simply LastOpened could imply a DateTime return type without including the return type in the property name. If it cannot be avoided, then a name like FileOpenedTime is consistent with the .NET guidelines, consistent with Framework property names, and unambiguous.

Answer 2

I too dislike the redundancy when specifying "Date" in a DateTime variable.

As an alternative you could use:

DateTime OpenedOn { get; set; }

Naming methods is hard if a reader is unaware of the context; If this method exists in a class used to store properties of a file then:

var fileOpenedOn = file.OpenedOn;

would read well.