Соглашение об именах для свойств даты

Question

Это не столько вопрос, сколько запрос комментариев.

Я всегда ненавидел включение даты в именованное свойство или переменную, которая является типом даты или даты и времени. Например:

DateTime DateFileOpened {get; set;} 

Мне кажется, что я включаю тип данных в имя переменной.

То, что я остановился на это, чтобы использовать слово «когда» вместо даты, например

DateTime WhenFileOpened {get; set;} 

Вообще, я украл это от использования является или в логических переменных/свойства.

Итак, вопрос: имеет ли кто-нибудь лучшее соглашение об именах для дат?

Answer 1

Я тоже не люблю избыточность при указании «Даты» в DateTime переменная.

В качестве альтернативы вы можете использовать:

DateTime OpenedOn { get; set; } 

методы именования трудно, если читатель не знает контекста; Если этот метод существует в классе, используемом для хранения свойств файла, то:

var fileOpenedOn = file.OpenedOn; 

будет хорошо читать.

Answer 2

Я обычно использую «date_» в качестве префикса:

date_created 
date_end 
date_deleted 
date_modified 

Затем Вы можете положить именование на сегодняшний день, как «date_FileOpened»

Answer 3

MSDN naming conventions for properties указать, что имя свойства должно быть существительным или существительным, критерием, который DateFileOpened удовлетворяет, но WhenFileOpened - нет.

В этих случаях это может помочь проверить имена свойств, используемые основными кластерными классами .NET. Следующий код будет извлекать имена всех свойств типа DateTime из всех загруженных сборок:

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); 

вывода показывает несколько соглашений на месте.

1. ______Date, ____Time (примеры: System.Net.Mime.ContentDisposition.CreationDate, System.Net.HttpWebRequest.Date, System.Timers.ElapsedEventArgs.SignalTime). Использование Date само по себе может сбивать с толку, когда и дата и время могут быть возвращены, но Time сам по себе можно считать менее двусмысленным. (Свойство, которое возвращает время без даты будет иметь тип возвращаемого TimeSpan, а не DateTime.)

2. _____DateTime, _____TimeStamp. (Примеры: System.Globalization.GregorianCalendar.MinSupportedDateTime, System.Diagnostics.TraceEventCache.DateTime, System.Net.Cookie.Timestamp). Это соглашение многословно, но недвусмысленно, что предназначена вся временная метка (дата + время).

3. Ни один. (Примеры: System.Net.FtpWebResponse.LastModified, System.Globalization.DaylightTime.Start, System.Net.Cookie.Expires). Не включая тип возвращаемого имени в соответствии с большинством имен свойств (String.Length, а не String.LengthInt).

Поскольку нет последовательного подхода, любой из этих шаблонов может считаться приемлемым.

В качестве предпочтительного варианта, однако, DateFileOpened предполагает, что файл можно открыть только один раз. Если это не так, имя свойства, например FileLastOpened или даже просто LastOpened, может означать возврат типа DateTime без указания типа возврата в имени свойства. Если этого избежать нельзя, то такое имя, как FileOpenedTime, согласуется с рекомендациями .NET, совместимыми с именами свойств Framework и недвусмысленными.